Re: [arch-general] Ncurses over ssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2014-07-30 09:21, luc.li...@mailoo.org wrote: Sorry, I wasn't clear enough : I open the connection with ssh [ip] -R :localhost:. Once this is done, I launch netcat -l -p on another terminal and netcat localhost on the server. Normally, netcat on the server should read its stdin and send it to localhost:, which is forwarded to my local computer, so I should see it on the netcat listening. But the netcat on the server simply exits without any error message, even in verbose mode. I don't know where the error can be. It worked when I tried local port forwarding, with the netcat listening on the server and sending messages from my computer, but that's not what I need. Maybe it is a firewall issue ? I don't know much in networks and I don't know how to debug that. The steps you described here work for me. I don't think that this is firewall issue. This looks like an ssh issue. Try running it with: ssh -vvv ... - -- Timothée Ravier -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJT2KzoAAoJENsngY94aI+DWCEH/jg+wK9VsBEFrXzLG1zyMEOa s9Lj0fVfLhTqlqhV8W72hYJDiycYVbNUDUIkf6/9dYHjM0hZnfL/lWPdZHQM78XB mLLZYmjozfkDZKpKgzDiOvcfO9JBGbZ7EaMAgjF4JfHVojLZtatEDxLWDUunLA9Z lCvnSguX/PE2y9bgnY5VrhsxAmwvVeNKMatH6cgx5020fklRjEpSAb1H1SI1bJB2 YzKvlbS0YMCYj7wIa1KFlESxUaubS9VbYlj/OWIogwoMmkoc2svT5U7J7s1tAbLL 8uxHkUeKgY3ek5xKij/BdQYe08R1P9VWXAMUL+7wYgM9UyImAmXmgsd+Jvr+t5c= =odnO -END PGP SIGNATURE-
Re: [arch-general] Ncurses over ssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2014-07-26 22:09, luc.li...@mailoo.org wrote: In a totally unrelated matter, do you know how to make a remote program launch local scripts through ssh ? You may use ssh -R to open a remote socket forwarding packets to your host and then send commands through it: ssh my.server.com -t -R :localhost: -- ... Here is how I did it, with newsbeuter in a tmux: http://tim.siosm.fr/blog/2014/02/16/first-rust-prog-and-rss-reader-update/ - -- Timothée Ravier -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJT12gtAAoJENsngY94aI+Dz8cIAKNQImyDaw3fVZybyacro67r jqEhql4jZVoe6fzKH1JotZQT6x5eeqqHFbybez287QmRlsITuvHRNknjJMKCzHNp 1wvn3wxLoOP8Mz2ip9Rlyb13LKaCWX4IvQc7nZvlneOikIJcAhtkrRlRWXoTns4x /HzFywjehYhiB1nz49UCksN9FGQo7+fJhmmzvHZ0KAG0+zR2pfDxxyuiQU0OGwZ4 y0yy2j2PVzhD1Bm/QZsX/m/icdm1voVgfc18iOYwMNIA+co37a7UeJxlN9jBOExo VmmQb5VH+nZ3feQCWdoHJvQAg/Z6O30Z8GYj/ueg4ZrEe3CAQahC2fbHyZ05+aQ= =fJcy -END PGP SIGNATURE-
Re: [arch-general] Ncurses over ssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2014-07-29 20:26, luc.li...@mailoo.org wrote: On Tue, Jul 29, 2014 at 11:23:57AM +0200, Timothée Ravier wrote: You may use ssh -R to open a remote socket forwarding packets to your host and then send commands through it: ssh my.server.com -t -R :localhost: -- ... I tried this, but I can't get the port forwarding to work. Testing it using netcat, I can get the local port forwarding to work, but netcat exits without printing anything (even in verbose mode) with the remote port forwarding enabled. Do you know where the error can be ? I'm not sure I understand what's your issue here. This command will only forward any packets sent to localhost: on the server to port on the client. You still need a program listening on port on the client (either sshd, telnet, my sample program...). Here is how I did it, with newsbeuter in a tmux: http://tim.siosm.fr/blog/2014/02/16/first-rust-prog-and-rss-reader-update/ This is a good link, that's exactly what I want to do. :) - -- Timothée Ravier -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJT2DTwAAoJENsngY94aI+DvycIAJwCit5T2y8H2rqdpS5GmLag NI14nJgy/RAUJWXm8CHmqEKtrNcAJLfDjWuKaUpD3yUGK+lSxyqoPg59mFneCAm8 82xNZCjejt2uMyQ1E6+QUC0Md5ech4x9Flgw7DTNvM4skEv55rsBq2uzEItWPfK6 4rBYu3ezYUohIYCE+59GxE/b7ZaviknCPjeW+c4GCikgPL3ux9+bQRk7jgsQ6H21 icn4ZONiCwN1WngdlPxC0jkRYDIxfRl8gBag+913tD0YzN/HUTEv0pR8eFCs79WM P0iZosKyaWHtVS05jeG3UU7vNEs/jkGGQvhuuesjix8U01FOktk88suX44lmefE= =muZU -END PGP SIGNATURE-
Re: [arch-general] Changing sizes of panes in a vimsplit resets scrolling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2014-06-15 23:49, Kyle Terrien wrote: I have narrowed this down to gvim/vim-runtime 7.4.307-1 and later. Earlier versions of the package do not have this issue. I am asking here because I am unsure if the issue is package related or upstream. I can reproduce this, with and without plugins. Neovim is not affected. Please file a bug upstream. If possible, you should narrow it down to the specific commit creating the regression. - -- Timothée Ravier -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJTnsg4AAoJENsngY94aI+DEWIH/Awq/8oLKFOkxUJgOKn5wZcc 23QpUfe+gBCGGWST1TIS761KoYiL/6mL88lVkxmtkTOAj8/a5lOIih3ratwWDCW9 WmpLrzaPKO+Wla66NDdtd4d5AeFQF2Y9GJ3dr2A3vz9AGVzYN/tDRkgJ3H6i0Awg mbAfaMm7fC7YYRb5KjWJgzoxe4NPrIQjmeMQYAfjUqMRULRmEOjUnR3TreUp5oWe /ONTLGP0T/dM1MavsC2w3DBdPIq6B30717nMJDR6pbzwQvNoA47FUeGA5CcRqZn5 Y5jcD7bLUqYt2lBjswzc8o0Z+a5ywjJ3AJgCRiX7Rlhwl8xP9roIBN3g8REbyE4= =tWCa -END PGP SIGNATURE-
Re: [arch-general] CA certifcates
On 29/05/2014 04:30, Eduardo Machado wrote: But... This week, after a system upgrade both Firefox and Chrome, stopped to reflect this, even after i did all the above process again. Firefox and Chrome are not using the ca-certificates package? Is there a way to do what i'm trying to do (a central point to manage certificates for all apps, especially browsers)? Fedora has been working on something close to what you'd want: one place to manage all certificates: http://fedoraproject.org/wiki/Features/SharedSystemCertificates I don't know how hard it would be integrate this into Arch Linux. And, a last question, is there a way to run a script after a specific package upgrade? I think this has been discussed at some point but this hasn't been implemented yet as far as I remember. -- Timothée Ravier
Re: [arch-general] libpng warning - qt application
On 27/05/2014 17:43, Guus Snijders wrote: I'm still curious to know how one can find out which files are opened by any program during startup; strace mainly showed which files could not be found. Did you make sure to trace children too? 'strace -f -e trace=open myapp' should do it. -- Timothée Ravier
Re: [arch-general] static libraries in packages
On 14/05/2014 13:51, Christian Hesse wrote: Is it possible to fix binutils testsuite? Remember the security flaws in zlib? Does anybody know what package has been built against static zlib? https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/mupdfid=c34f53eeb8efd6b4b033c2fdc58d0a329efdeeef This brings the static libraries back, but there is no reason. libmariadbclient ships with static libraries because a package from AUR (neko) requires it. I think anybody should fix neko, but shipping official packages with static libraries in this situation is just stupid. Removing static libraries (and keeping them away!) should be treated more strict. Please file bug reports. One for each package. -- Timothée Ravier
Re: [arch-general] Heartbleed-bug in OpenSSL 1.0.1 up to 1.0.1f
On 08/04/2014 17:29, Neal Oakey wrote: Many other Distributions have build there own patch, what is with us? As a reminder, there is now a Wiki page that tracks all security issues and their status in Arch Linux [1]. If it's not there, please either add the issue in the wiki by yourself and file a bug report (see [2]) or drop by on irc at #archlinux-security (on Freenode) and let us know about it. [1] https://wiki.archlinux.org/index.php/CVE-2014 [2] https://wiki.archlinux.org/index.php/Arch_CVE_Monitoring_Team -- Timothée Ravier
Re: [arch-general] Linux container
On 12/02/2014 20:06, ProgAndy wrote: To secure your container you have to make sure that the users in the container will be represented as different ids to the host system. Especially root in the container must not have root access to the host. Here is some more reading material for you: http://libvirt.org/drvlxc.html#secureusers http://libvirt.org/formatdomain.html#elementsOSContainer The (kernel) feature discussed here is the user namespace. It enables cointainers to have a different uid/guid mapping than the one on the host. This should be a safe way to allow root users inside containers whitout giving them full access on the host at the same time. This feature is relatively new and is not enabled in the default Arch Linux kernel: $ zgrep USER_NS /proc/config.gz # CONFIG_USER_NS is not set You'll have to build a custom kernel. -- Timothée Ravier
Re: [arch-general] Kernel 3.13
On 27/01/2014 21:07, phanisvara wrote: (..) Jan 28 01:58:33 phani kernel: [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CEDE (len 62, WS 0, PS 0) @ 0xCEFA (...) Have a look at https://bugs.freedesktop.org and search for your bug in the DRI section. If you find none, report it with full dmesg log. -- Timothée Ravier
Re: [arch-general] Default value of j in makeflags of makepkg.conf
On 03/01/2014 16:24, Martin S. Weber wrote: because for each new occurrence, it will have to be determined manually: concurrency brings non-determinism with it. Many of these pkgs built just fine (tm) for developers a, b and d (not only on, but also on multi-core and/or SMP machines) while it didn't for devs c, f, g, and, much worse, for users u, y and z. I mean, feel free to learn the sane default for (said 590) pkgs from pkgsrc, or consider the process that spans from 2007 until now, where pkgs still are flagged MAKE_JOBS_SAFE after the first user has run into them not building. As far as I know, MAKE_JOBS_SAFE and 'options=!makeflags' are packaging tricks to work around an upstream bug. Enabling parallel builds by default would only reveal bugs, which is a good thing generally, thus I don't understand your objections. Cheers, -- Timothée Ravier
Re: [arch-general] Default value of j in makeflags of makepkg.conf
On 03/01/2014 17:46, Martin S. Weber wrote: Sermons from packager from pkg systems A, B, C, D (...) sooner or later provoke ignorance from upstream dev (...). No sermons should ever be made to upstream by packagers. Upstream should not be blamed for bugs, but helped with. This is free software, let's just try to be nice to each other. In other words again: you might find what you consider a bug, but upstream will not care, ignore your patches, not listen to you or simply get annoyed (witnessed instances of this before). As you've said, the packagers should provide the patch to fix the issue. If upstream does not want that then it's fine, the packager should use the trick. I hardly understand why would any upstream refuse a patch to fix parallel build issues. Read e.g. this message from the author of SQLite and fossil about packager's need/want for splitting dynamic libs from projects using said dynamic libs (sqlite in that instance): http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14153.html I'm not sure this issue is related to the current discussion, as he is upset with distributions packaging old software with new one, something never done in Arch as far as I know: I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. And I think I remember that Arch does have static libraries when it makes sense. IMHO you're just about to open a can of worms that only you yourself will want to swallow, for a) the greater good of squishing bugs and b) no change in the big picture. There is nothing to swallow here as there already is an option to bypass parallel build. I'm not opening anything either as I'm just not against the proposed change. It looks like a convenience change, which does not really have arguments against it as it's just a default setting. -- Timothée Ravier
Re: [arch-general] Patch for update-mime-info slowness
On 05/12/2013 20:10, Lukas Jirkovsky wrote: On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: I'm not sure whether this should classify as a bug report. How could this not qualify for a bug report? Maybe this should also be discussed upstream as this is not a Arch specific issue as far as I understand. Maybe they do have reasons for calling fsync so heavily. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Again, file a bug upstream. -- Timothée Ravier
Re: [arch-general] Segfault in Pool according to dmesg
On Sun, 2013-12-01 at 17:14 -0500, arch-general-requ...@archlinux.org wrote: On 30/11/2013 17:54, Mark E. Lee wrote: pool[2129]: segfault at 8 ip 7fbddb60b1b5 sp 7fbd87ffec40 error 4 in libglib-2.0.so.0.3800.2[7fbddb5a8000+fe000] A one line error log is a bit short don't you think? Why don't you give us more context? Have you searched the web? I found at least one old issue that could give a clue about what's happening. You should provide those informations right away. We shouldn't have to ask for this. That's the only error I got and it didn't appear upon reboot. It didn't have any discernible effect on the system. I also searched for the issue on the web and didn't find any information (the word pool is a very common word). Thanks for the response though. If found those bugs which look like they could match your problem, but we need more context to find what's the problem (keyword: pool segfault): https://bbs.archlinux.org/viewtopic.php?pid=1092046 https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1174020 https://bugzilla.redhat.com/show_bug.cgi?id=918295 I you can't reproduce the issue, it's going to be really hard to diagnose. If you searched the web, please don't forget to say so in your first email, including why you think the results you found don't match. Tim
Re: [arch-general] Segfault in Pool according to dmesg
On 30/11/2013 17:54, Mark E. Lee wrote: pool[2129]: segfault at 8 ip 7fbddb60b1b5 sp 7fbd87ffec40 error 4 in libglib-2.0.so.0.3800.2[7fbddb5a8000+fe000] A one line error log is a bit short don't you think? Why don't you give us more context? Have you searched the web? I found at least one old issue that could give a clue about what's happening. You should provide those informations right away. We shouldn't have to ask for this. Tim
Re: [arch-general] GDB does not work, sometimes
On 23/11/2013 13:14, Rodrigo Rivas wrote: So it looks like some kind of permission issues. Maybe something related to the recent SELinux changes? Nothing related to SELinux support has been merged in official Arch packages for now (as far as I know). And even if it had been, SELinux would certainly not be enabled by default without a big news. You can cross this one off. Tim
Re: [arch-general] virtualbox CPU issue / upstream has fix
On 21/11/2013 23:23, Genes Lists wrote: Any chance of getting the fix in the arch testing repo? What's stopping you from opening a bug report in the Arch bugtracker? Tim
Re: [arch-general] selinux groups not working
On 09/11/13 14:42, piruthiviraj natarajan wrote: I am trying to install selinux on my system from Timothee's repos. But I am only able to install package group selinux but the *selinux-system-utilities*, **selinux-userspace, **selinux-policies* and *selinux-extras* package groups doesn't seem to be working. [root@arch ~]# pacman -S selinux-system-utilities selinux-userspace selinux-policies selinux-extras error: target not found: selinux-system-utilities error: target not found: selinux-userspace error: target not found: selinux-policies error: target not found: selinux-extras Hi, I removed those groups as most of the packages are required anyway for SELinux support, and there is not point is keeping them in different groups. I kept only the selinux group. I'll re-introduce an extra group as soon as I can make sure a package is really extra and isn't required for normal operation. Tim
Re: [arch-general] selinux groups not working
On 09/11/2013 15:05, piruthiviraj natarajan wrote: On Sat, Nov 9, 2013 at 7:30 PM, Timothée Ravier sios...@gmail.com wrote: I removed those groups as most of the packages are required anyway for SELinux support, and there is not point is keeping them in different groups. I kept only the selinux group. I'll re-introduce an extra group as soon as I can make sure a package is really extra and isn't required for normal operation. I found that the linux kernel was not included in the selinux group. Yes, I will fix this soon. But SELinux support should be included in the official Arch kernel from 3.13 (according to the bugtracker). So this isn't much of a problem. I think users would mostly prefer one group called 'selinux' and it will just install all the required packages for a minimal selinux to be working on a system. That's exactly what I'm going to do (no ETA): * selinux group: only what's strictly necessary; * selinux-tools/extra group(s): other useful, not mandatory, packages. Tim
Re: [arch-general] can't locally sign Siosm key selinux
On 04/11/2013 14:41, piruthiviraj natarajan wrote: pacman-key --lsign-key C8D83B6AE4B8685A7290545FDB27818F78688F83 - Locally signing key C8D83B6AE4B8685A7290545FDB27818F78688F83... == ERROR: C8D83B6AE4B8685A7290545FDB27818F78688F83 could not be locally signed. Just to make the solution public: don't forget to run pacman-key as root! Tim
Re: [arch-general] SELinux packages status update
On 03/11/2013 21:32, Timothée Ravier wrote: Status of core packages that requires patches or rebuild: * findutils: need SELinux patch, can be upstreamed, but is upstream still alive ? * pam:rebuild '--enable-selinux' flag for Linux-PAM, patch for pam_unix2, which only removes a function already implemented in a library elsewhere. Is there an upstream here? I couldn't find one; * psmisc: small patch, already upstream. Will be in version 22.21; Total: 1 rebuild as-is, 8 rebuild with additional flags/config, 3 rebuild with patches required (with one already upstream and two potentially dead upstream). Quick update here: * The findutils patch is already upstream and in the latest *development* release (4.5.10). No ETA for the stable release. They need help fixing bugs if someone is interested [0]. * According to Thorsten Kukuk (latest known pam_unix2 developer), pam_unix2 is no longer under development and we should use Linux-PAM, which we are using already. Is there a reason pam_unix2 is still in the repository? So the only patch not already upstream is the one with a dead upstream. Now let's go back to work on the policy... [0] https://savannah.gnu.org/bugs/?group=findutils Tim
[arch-general] SELinux packages status update
Hi, I've updated all the SELinux related packages in the AUR. I've changed most packages names to better fit with upstream names and AUR naming policy (selinux-pam - pam-selinux; selinux-usr-libselinux - libselinux). I'll keep the old ones a week or two, just in case, then I'll ask for deletion. I've only tested those packages in SELinux _disabled_ mode as currently there aren't any usable policy. I'll be working on this from now on. Status of core packages that requires patches or rebuild: * linux: rebuild. bug opened in the Arch bugtracker; * coreutils: rebuild (links with libselinux); * cronie: rebuild '--with-selinux' flag; * findutils: need SELinux patch, can be upstreamed, but is upstream still alive ? * openssh:rebuild '--with-selinux' flag; * pambase:configuration changes to add pam_selinux.so; * pam:rebuild '--enable-selinux' flag for Linux-PAM, patch for pam_unix2, which only removes a function already implemented in a library elsewhere. Is there an upstream here? I couldn't find one; * psmisc: small patch, already upstream. Will be in version 22.21; * shadow: rebuild '-lselinux' and '--with-selinux' flags; * sudo: rebuild '--with-selinux' flag; * systemd:rebuild '--enable-selinux' flag; * util-linux: rebuild '--with-selinux' flag; Total: 1 rebuild as-is, 8 rebuild with additional flags/config, 3 rebuild with patches required (with one already upstream and two potentially dead upstream). I think this looks good! Suggestions for packages are welcomed as AUR comments or issues on GitHub: https://github.com/Siosm/siosm-selinux A repository with signed packages for x86-64 only is available at http://repo.siosm.fr/siosm-selinux/ (See https://tim.siosm.fr/repositories/ if you need instructions or GPG public key). I'll also update the Arch Wiki SELinux page soon. I'll setup an other repository for the SELinux policy as soon as I have something which can boot in enforcing mode. Cheers, Tim
Re: [arch-general] SELinux packages status update
Hi, On 03/11/2013 23:50, Karol Babioch wrote: Looks great. As soon as I have some spare time I will give it a try. Thanks! If you're building by hand, have a look at the quick README here: https://github.com/Siosm/siosm-selinux/blob/master/README.md I'll setup an other repository for the SELinux policy as soon as I have something which can boot in enforcing mode. What is your current approach to come up with a reasonable policy? In what fashion do you plan to split up the policies itself? Will your policies be based upon the reference ones (see [1])? [1]: http://oss.tresys.com/projects/refpolicy/ As far as I know, the Fedora SELinux policy is quite comprehensive and includes most of the software used in Arch Linux. If I'm not mistaken, it is based on the reference policy made by Tresys. However, I'm not planning on supporting non-MLS/MCS systems and I will probably only make one policy with support for all the SELinux features (including MLS/MCS). According to me, this will avoid the current status with the three Fedora policies. This is a personal opinion: it feels like the only one working is the default one (targeted) and the two others (minimal and mls) receive minimal testing and are thus mostly useless... I don't think we need to maintain several policy versions and I don't want to waste time supporting policies I won't use. The battle plan is: * strip modules from the Fedora policy to the minimum required to boot a minimal installation; * fix those modules; it's probably mostly going to be about paths, as Fedora uses libexec which we don't have, and has not yet merged /usr/sbin with /usr/bin; * add stripped modules back progressively. Cheers, Tim
Re: [arch-general] Revisit official SELinux support
Hi Nicky, On 01/11/2013 10:36, Nicky726 wrote: First of all, since I have been very busy lately, I didn't have time to keep the AUR packages up-to-date, and the prospects in the near future don't look very good... So, if there is a willing hand among you, I can pass the maintanence to you, together with offline git repos and scripts I use to keep the packages in sync with [core], if that is of any help to you. I'm currently updating all the userspace packages to the latest release. I will probably maintain them from now on. You can orphan them in the AUR, I'll adopt them. I've opened https://bugs.archlinux.org/task/37578 asking for SELinux support in the default Arch kernel, which will simply the process for those who want to try SELinux. I'll make the built packages available too. Tim
Re: [arch-general] Revisit official SELinux support
On 31/10/2013 00:36, Allan McRae wrote: On 31/10/13 09:36, Timothée Ravier wrote: Only packagers will be impacted as there are still some patches needed and this could slow down 'core packages' updates when issues arise. But fixes usually comes quite quickly as both Fedora and Gentoo maintain packages with SELinux support. Requiring patches not accepted upstream is an immediate blocker. Sorry, I chose my words poorly. I meant two things: * First, patches required for SELinux should be pushed and accepted upstream. I don't know the current state about those. I'll post an update later. * Future core packages releases may require patches to make SELinux work or even make the packages build with SELinux activated. On this front there isn't too much to be concerned of as both Gentoo and Fedora SELinux folks are affected by those issues too and will surely provide patches which we could push upstream if necessary. I see a couple of issues that will also have to be resolved for SELinux on Arch to be usable: * It needs some support in pacman, otherwise package updates will be painful; I'm interested as a pacman developer what support would be needed, but that too is a likely blocker. First, as I don't know pacman internals very well, I may say/assume stupid things. Please correct me if that happens. Among other things, SELinux use labels stored in files extended attributes to do access control. You can reset those attributes to the default values from the policy using the restorecon command tool or using a function in the libselinux library. However, I suspect that updating packages using pacman will overwrite those attributes, requiring relabeling at each update as we don't know which files had their attributes changed. What's needed is a switch/option in pacman to restore SELinux labels on both new files and files that have been overwritten during update. I'll work on a patch once I got a test system running again. Is this something unacceptable to put in pacman? Tim
Re: [arch-general] Revisit official SELinux support
On 31/10/2013 18:49, Leonid Isaev wrote: Indeed, we've had AppArmor for over a year now, yet entire related userspace is in AUR, and all profiles have to be hand-written or adapted from OpenSuse or Ubuntu ones... I wasn't aware of that, thanks for pointing it. Well then I guess simply enabling SELinux support in the kernel could be considered as it will bring us to the same point as AppArmor. I'll open a bug report for this. Tim
Re: [arch-general] How to show (kernel) messages by journalctl?
On 13/10/2013 01:51, Ralf Mardorf wrote: yesterday I rebooted at 17:51 from linux 3.11.4-1 to linux-rt 3.10.14_rt9-1 and then shut down at 17:55. How can I get log data, kernel messages of this startup? To get log data from a specific startup, as root/using sudo, run: # journalctl -b -1 _TRANSPORT=kernel where -b -1 means the previous boot (-b -2 meaning the boot before and so on). You can also use: # journalctl -b -0 _TRANSPORT=kernel to show current boot messages, which is equivalent to: # journalctl -k Tim
Re: [arch-general] Generate /etc/blkid.tab
On 24/09/2013 11:45, Ricardo Catalinas Jiménez wrote: I need to update the content of this file because I modified my partition table, but I can't see how googling around. According to the man page, this file is only generated if your system doesn't have a /run directory, which would be an odd thing for an Arch system, or if you have a custom config file for blkid. Running 'BLKID_FILE=/etc/blkid.tab blkid -c /dev/null' as root should update it. Is this file actually used? How is it generated originally when installing its owner package? According to https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/util-linux, it is not generated at install time. You may want to have a look at custom packages you have installed that could rely on this file. Tim
Re: [arch-general] Another Major glitch now
Le 28/01/2012 18:41, P NIKOLIC a écrit : It seems for some strange reason the Hard disk may be full well the / partition at least si the install may not have completed now have to think about this one see if i can resize the / partition i have space on /home need to shrink that and extend / good fun .. not . Hi, I hit the same problem while updating through KDE RC. I've filled a wish in KDE bug tracker (https://bugs.kde.org/show_bug.cgi?id=290778) to alert the user on start if /, /tmp or /home is full as it affects KDE applications way out of proportions as compared to GTK+ applications for example. I'll try to work on something if I find the time to do so... Tim
Re: [arch-general] [arch-dev-public] KDE 4.8.0 hits [testing]
Le 26/01/2012 08:24, Andrea Scarpino a écrit : Hi all, overnight the mirrors synced the latest stable release of KDE. I had no many time to work on it, so I pushed it in [testing] just to be sure everything's ok. As I can't send to arch-dev-public, I'm sending this here: This release seems good to me. (signoff x86_64 ?) I've been using the packages available in kde-unstable, and I must say the packaging is well done! Good job! Tim
Re: [arch-general] security problem in X with screen saver
2012/1/19 Magnus Therning mag...@therning.org: On Thu, Jan 19, 2012 at 08:58, Divan Santana di...@s-tainment.co.za wrote: Hi All, As per http://www.phoronix.com/scan.php?page=news_itempx=MTA0NTA There is a quite a serious security problem. Is there a patch coming out soon? Does anyone yet know a workaround to this in the meanwhile? Can it be announced? Have you verified that your system? On my system none of the keys mentioned in that article have the reported results; they all jumps out to virtual terminals. I have not made any changes to the stock Arch config that would affect those keys. Use the Ctrl + Alt + * from the keypad to trigger the bug. As explained in the article, this is purely Xorg related. Use vlock for example if you want to avoid the problem. Tim
[arch-general] Problems with pacman 4.0.0-2
Hi, I'm using pacman from testing and I ran into some troubles. I set SigLevel = Optional TrustAll in pacman.conf, but I'm still getting a lot of warnings even after I add the keys to the repo. It also takes an ENORMOUS amount of time to do I don't know what right after checking packages integrity, and then fails with : invalid package or corrupt signature _without_ telling me which package had a problem. As a workaround, I'm using SigLevel =Never, but well, this isn't the solution. It fixes both the performance issue the signing (as expected). I tried using an other mirror, hoping that was only a temporary corruption, but this isn't. I attached a sample pacman output log. As for performance concerns, I'm using an intel quad core cpu, with 8Go ram, and pacman doesn't seem to use any ressource at all. It looks like it's the gpg-agent command launched by pacman that takes all this time to complete (and fail in the end ?). I don't have a clue what it is doing, because that's why I used Optional TrustAll in the first place. I got three Arch box which are affected by this problem (on different networks, if it matters for gpg-agent). Any ideas are welcome. This could be unrelated to pacman itself. Tim
Re: [arch-general] Problems with pacman 4.0.0-2
Le 18/10/2011 22:17, Jakob Gruber a écrit : On 10/19/2011 12:09 AM, Timothée Ravier wrote: Hi, I'm using pacman from testing and I ran into some troubles. Edit /etc/pacman.d/gnupg/gpg.conf to use a different keyserver, for example: keyserver hkp://pgp.mit.edu Seems like keys.gnupg.net is currently having some issues. The long timeout is fixed in git. Thanks ! It fixed my problem. But still, would be nice to show exactly which packages are not valid. Tim
