Re: [arch-general] Why doesn't svntogit/{community, packages} describe cloning (or download) of individual packages?
Am 05.08.2017 um 07:15 schrieb David C. Rankin: > All, > > After abs demise, I ran into needed to rebuild gtk2 with --enable-debug=yes > for a gtk.org bug report. Finding the packages from the normal package search > is simple, but when you are on svntogit -- the only helpful discussions are to > clone the entire repository, e.g.: > > Clone > https://git.archlinux.org/svntogit/community.git > git://git.archlinux.org/svntogit/community.git > ssh://git.archlinux.org/srv/git/svntogit/community.git > > Nowhere are there options to download or clone the current repository (like > github) and nowhere is there a mention of 'asp export pkgname'. There is no > wiki for asp and the only mention is in the ABS page -- and that information > relates to the svn part of the tree. > > 'asp export' works fine, but if there is nothing on the svntogit that > directs folks to it, the only information given is to 'Clone' as shown above. > (which will result in roughly 500M each for community and packages if the > instructions on the page are followed (compared to what was 88M total for > abs). > > Can individual clone or download urls be provided on each package page like > with github? Can references to 'asp export' also be provided? Those seems like > things that should be done to help with the transition away from abs and help > preserve bandwidth. > git clone --branch packages/gtk2 --single-branch https://git.archlinux.org/svntogit/packages.git gtk2 Regards Thomas signature.asc Description: OpenPGP digital signature
Re: [arch-general] Mount point of MTP devices?
Am 02.04.2017 um 07:06 schrieb Rijul Gulati via arch-general: > Hello, > I have recently installed Arch on my desktop machine (KDE). > I want to access android device (MTP) from terminal. The device is > accessible from file manager (Dolphin). This means it has to be mounted > somewhere (right?). No. MTP is not a file system. There are some pseudo file systems that could mount it, but obviously with limited functionality (after all, it's not a file system). mtpfs ([1]) seems like an obvious choice, but I have never used it, so I don't know if it even works. As others have said, Dolphin accesses it via the kio framework. [1] https://www.archlinux.org/packages/community/x86_64/mtpfs/ signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch GNU/Linux install for beginners and new users
Am 22.09.2016 um 19:54 schrieb Francis Gerund via arch-general: > Chris, > Thank you for your interest. Perhaps you may find this helpful: > > http://www.gnu.org/gnu/why-gnu-linux.en.html No, we don't find this helpful at all. The FSF has no right to forcefully rename what we call our OS. We call it "Arch Linux" because we like that name. We don't call it "Arch GNU/Linux" because that sounds stupid. The GPL explicitly allows us to distribute any software licensed under it freely. There is no clause in the GPL that we have to include the name "GNU" in our name in order to do so. By the FSF's argument, we should call it "Arch freedesktop/GNU/systemd/KDE/GNOME/Linux", but that sounds even worse. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
Am 01.02.2016 um 20:35 schrieb Tomasz Kramkowski: > The newbies this change is aimed for are exactly the sorts of people who > might unwittingly rm -rf /. Arch Linux is not aimed at newbies. There's been lots of panic over this issue, yet it took several years of UEFI being in the field for someone to actually trigger it. I guess it will be fixed in the kernel very soon. Until then we can calm down and start panicking - every local privilege escalation bug is worse than this stuff. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Please update to OpenVPN 2.3.8
Am 12.09.2015 um 10:25 schrieb Florent M: > Hi everyone, > > There are some reasons that openvpn in core is 2.3.6 ? > > Please update openvpn package to 2.3.8 asap. > > Just update PKGBUILD to 2.3.8, it works It does NOT work. It fails to launch when using a passphrase-protected private key. The whole code path that is supposed to call systemd-ask-password is borked. There will be no update until this is fixed - unfortunately, I did not get to posting to their mailing list yet. , and remove openvpn@.service > because systemd service files are now provided by OpenVPN. This is already done in my local working copy, probably did not check it into trunk yet. signature.asc Description: OpenPGP digital signature
Re: [arch-general] SSH security
Am 06.01.2015 um 14:29 schrieb Ido Rosen: Just wondering, how do Arch devs feel about implementing these recommendations by default in Arch's openssh package? Or would this be something worthy of an AUR package? https://stribika.github.io/2015/01/04/secure-secure-shell.html Especially interested in the moduli, KexAlgorithms, and Cipher selection config changes. I guess this would be a great topic for the Arch wiki. The latest OpenSSH version supports all these fine things (like ed25519 ecdh). If you want to improve things globally, try to talk to the OpenSSH developers about their defaults. signature.asc Description: OpenPGP digital signature
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
Am 21.12.2014 um 22:48 schrieb Leonid Isaev: On Sun, Dec 21, 2014 at 09:49:42PM +0100, Sebastiaan Lokhorst wrote: Thanks everyone for your responses! It seems that gdisk is still favorable for advanced tasks, but fdisk is can be used for basic tasks, as are usually required by beginners. No, that was my point: for advanced tasks you need neither. I never read the beginners' guide, and don't care how it is formatted. I am just trying to un-confuse people regarding the whole GPT vs MBR thing... If you want to un-confuse people, you can really simplify the instructions by using only fdisk in the beginner's guide. Then you have the same tool for both GPT and MBR. This is not true. Some low-end modern machines completely drop legacy BIOS boot. So booting via UEFI is required, and thus GPT is required. I really doubt this. Are you saying that some vendors on purpose break such things as booting from an external USB key? I have a firmware that boots from USB fine in UEFI mode, but _only_ if it is formatted with MBR - it won't boot from GPT USB disks. Confusing, right? signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Changes to microcode updates
Am 28.10.2014 um 11:50 schrieb Paul Gideon Dann: On 27 October 2014 09:55, Christian Hesse l...@eworm.de wrote: Damjan Georgievski gdam...@gmail.com on Thu, 2014/10/23 19:40: On 12 October 2014 14:28, Thomas Bächler tho...@archlinux.org wrote: Intel released a new microcode update that disables an instruction on Haswell CPUs. However, Linux doesn't handle this very well and in combination with our glibc version, this essentially crashes your system. The solution is to use the new early microcode update mechanism that was introduced almost two years ago ([1]). This means we need to build microcode support into the kernel. Question: how do microcode updates interact with waking the machine from sleep? I've added the microcode update as an initrd, and it updated fine when I rebooted. However, having since suspended and woken my machine, the kernel log shows a second load of the microcode: [0.00] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [0.090603] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [0.111347] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [0.132113] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 [0.334871] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c [0.334881] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c [0.334886] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c [0.334892] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c [0.334931] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba [ 7802.735878] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.749970] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.764074] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 Note that CPU0 doesn't seem to have been updated. Suspending and resuming again yields a further update to CPUs 1,2,3, but not 0. I'm also getting sporadic failures to launch certain binaries, with an illegal hardware instruction error. I'm on kernel 3.17.1-1, which may have something to do with it. I'm aware that 3.17.2 will behave differently with regard to loading microcode. So is this expected behaviour? Any information / ideas / theories? In theory, the ucode should be updated after resume. I don't know if this is only true for the CPU which get disabled before sleep, or if CPU0 also needs an update. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Changes to microcode updates
Am 21.10.2014 um 11:36 schrieb Mike Cloaked: On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler tho...@archlinux.org wrote: These changes have been done precisely to avoid these problems, the first link and its responses summarize the situation pretty well. The file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt gives a method that should allow creating a combined initrd img file that anyone booting with refind EFI may be able to test. There are suggested methods to implement early microcode loading for the other main bootloaders in the arch wiki, but until now for refind it seems not to have been verified to work. It would be nice to see verification that early microcode loading has been successful using all the main bootloaders/bootmanagers, as well as direct efistub boot. A 2 minute Google search indicates that refind merely appends the initrd as a kernel command line option (initrd=) - refind, like gummiboot, is merely an EFI bootmanager and not a bootloader and thus relies on the kernel's EFIstub feature. Therefore, refind does not load the initrd itself, but delegates that task to the kernel. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Changes to microcode updates
Am 23.10.2014 um 21:58 schrieb Mike Cloaked: Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode? This is the timestamp that marks Intel's internal version. This is what I get: [0.00] lije kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Changes to microcode updates
Am 19.10.2014 um 19:54 schrieb Mike Cloaked: On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists li...@sapience.com wrote: For info - I have tried to get it working in refind and failed. I added a second initrd line in the boot stanza in refind.conf. But the firmware was not updated. I added to refind sourceforge report[1], perhaps Rod will respond. [1] https://sourceforge.net/p/refind/discussion/general/thread/7da6cd81/ It would seem that there might be some problems with this microcode update apart from the issues with bootloaders. See 1) https://lkml.org/lkml/2014/9/18/218 2) https://bugs.launchpad.net/intel/+bug/1370352 These changes have been done precisely to avoid these problems, the first link and its responses summarize the situation pretty well. signature.asc Description: OpenPGP digital signature
Re: [arch-general] systemd timers: switch default target to timers.target?
Am 08.10.2014 um 02:51 schrieb Sébastien Luttringer: On 06/10/2014 23:45, Thomas Bächler wrote: Am 04.10.2014 um 13:44 schrieb Neitsab: Why? Most of these timers should only be available when running a fully booted system. timers.target is pulled in by basic.target. This implies that startup of all normal services is delayed until the startup of these timers (and other units) has finished. This may make sense for socket or path units, but is entirely unnecessary for timer units, especially those that merely serve as cron replacements. Upstream recommends to stick to timers.target. If units should be delayed after others After= and Before= directives do the job. There is also OnBootSec= if you want to delay timers on a timed way. I don't care what upstream recommends, there is no reason for this target to exist and there is no reason to use it. Things get even worse, since you cannot order the unit After=something - since timers.target pulls the unit, it gets an implicit ordering Before=timers.target, removing lots of flexibility with regards to ordering (since timers.target is before sysinit.target). signature.asc Description: OpenPGP digital signature
Re: [arch-general] systemd timers: switch default target to timers.target?
Am 04.10.2014 um 13:44 schrieb Neitsab: Hi everybody, It seems like systemd now provides a target that is intended to gather all timers supposed to be activated after boot. This target that systemd now provides has always been available. Currently, three timers are statically enabled via symlinks in /usr/lib/systemd/system/multi-user.target.wants/ after install (logrotate.timer, man-db.timer and shadow.timer), while as already said systemd-tmpfiles-clean.timer is statically enabled via a symlink in /usr/lib/systemd/system/timers.target.wants/ (seemingly respecting new practice). On the other hand, util-linux' fstrim.timer, when enabled via systemctl, gets symlinked in /etc/systemd/system/multi-user.target.wants/. Other packages not part of base like extra/pkgstats or extra/mlocate also provide timers that once enabled, get symlinked to /usr/lib/systemd/system/multi-user.target.wants/. So AFAICT, there are quite some discrepancies concerning how systemd timers are implemented. I'd like to discuss whether Arch should switch default timers target for packages in base group from multi-user.target to timers.target, possibly doing so for other packages in official repos. Why? Most of these timers should only be available when running a fully booted system. timers.target is pulled in by basic.target. This implies that startup of all normal services is delayed until the startup of these timers (and other units) has finished. This may make sense for socket or path units, but is entirely unnecessary for timer units, especially those that merely serve as cron replacements. signature.asc Description: OpenPGP digital signature
Re: [arch-general] rp-pppoe: requires ppp=2.4.6
Am 03.09.2014 um 09:09 schrieb Thorsten Jolitz: Hi List, this morning I got the following error when trying to update (pacman -Syu): , | [tj@arch ~]$ LC_ALL=C syu | :: Synchronizing package databases... | core is up to date | extra is up to date | community is up to date | multilib is up to date | :: Starting full system upgrade... | resolving dependencies... | looking for inter-conflicts... | error: failed to prepare transaction (could not satisfy dependencies) | :: rp-pppoe: requires ppp=2.4.6 ` Should be fixed soon-ish (when your mirror updates again), sorry for the noise. signature.asc Description: OpenPGP digital signature
Re: [arch-general] bugs.archlinux.org - enable comments on closed issues
Am 23.08.2014 um 05:07 schrieb Nowaker: But closing the issue shouldn't end the discussion - the reporter may want to add something. It should do exactly that. The bugtracker is not a discussion board, it's a bug tracker. Fixed bugs are not tracked. If you need a discussion, there's plenty of other possibilities for that. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]
Am 13.08.2014 um 17:29 schrieb Damjan Georgievski: On 13 August 2014 17:26, Damjan Georgievski gdam...@gmail.com wrote: yey thanks for CONFIG_USER_NS=y ahh no, I'm stupid. Checked it on another machine and got excited before hand :/ anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel) I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit. If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]
Am 13.08.2014 um 19:40 schrieb Damjan Georgievski: anyway. is there a reason this is not enabled now? all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7, Ubuntu and Debian (at least on the backported kernel) I'd think about it, if the feature wasn't entirely useless. Despite the lack of official documentation, I found a document that described how it worked. After reading that document I concluded that the feature is a huge potential security risk with no actual benefit. What security risk exactly? There was one that I know of, and it was fixed. I am thinking about the risks that are yet unknown. If you give me a valid use case for USER_NS, I might reconsider, but every use case I can imagine is crushed by the limitations of the implementation. The use case is that you don't need root access to start a container. That's interesting - I was unable to get anything like this done. Maybe the LXC people are smarter than me after all. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Am 05.05.2014 15:05, schrieb Maciej Puzio: I have been testing the issue for a week. Daily timers are fired between 0:00 and 0:01 without exception - all timers at the same time, all machines at the same time, every day at the same time. The largest variation I have seen was 30 seconds. So yes, there is definitely an issue with AccuracySec=12h not being honored. However, whether timer accuracy is 30 seconds or 12 hours, this makes little difference to me, as both are unacceptable without the possibility to customize timer elapse time. Of course you can configure the elapse time, by adjusting the associated .timer unit. With anacron, there was no way to adjust the time, so this is a step forward. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
Am 24.04.2014 17:20, schrieb Maciej Puzio: I am sorry to say that the decision to replace cron.daily tasks with systemd timers is causing problems. After a routine update I noticed that my machines now perform daily maintenance tasks exactly at midnight. Not only is this time not optimal (too early), but all machines perform their maintenance at the same moment, which is far from ideal, especially for servers. Previously I had each server to perform daily cron jobs at various times, spread between 3 and 6am. On my machines this affects updatedb, man-db, logrotate and shadow, updatedb generating a lot of I/O and thus being the most problematic. I was not able to find any way to configure systemd to fire daily calendar timers at a different time of the day (please correct me if I missed something). So far I found two workarounds: This is supposed to be handled by the AccuracySec=, which is supposed to schedule timers at random times within the specified interval (in our case, 12h). I have no idea why this doesn't work, it's definitely worth looking into. 1. Override timer files and set OnCalendar with a specific time, rather than daily. This has to be done separately for each timer. Yes, bad solution. As I said above, we should try to figure out why AccurarySec= doesn't do anything first. 2. Restore cron.daily scripts and mask relevant systemd services and timers (i.e. revert the configuration to what it was before the update). The resulting config is simpler to manage than the first workaround (no separate time settings for each task), so I went with this one. This shouldn't be a permanent solution. signature.asc Description: OpenPGP digital signature
Re: [arch-general] On-boot delay due to timer units
Am 21.04.2014 18:56, schrieb Leonid Isaev: On Thu, 17 Apr 2014 21:31:07 +0200 AFAIU, there are 2 real issues here: 1. We hook to the boot process a bunch of disk-intensive operations which did not belong there in the 1st place. 2. Even if a boot delay for timers is implemented or the behavior of Type=idle units is fixed somehow in systemd, still all cron timers will be started in parallel which may result in a slow/unresponsive system. Note, that under anacron they were serialized by run-parts. The Linux scheduler and I/O scheduler are supposed to handle such workloads gracefully. The units are configured to be in the proper io scheduling class and with proper nice values. signature.asc Description: OpenPGP digital signature
Re: [arch-general] On-boot delay due to timer units
Am 17.04.2014 20:56, schrieb Leonid Isaev: Hi, Since anacron jobs were replaced with timers, I am seeing a noticeable delay before agetty prompt appears on machines which were unused for some time (due to update/man-db timers starting up simultaneously). TLDR: Anacron inserts a random delay between boot and running the jobs, so is it possible to simulate this behavior by including e.g. OnBootSec=... in the timers at next update? Or is this option incompatible with OnCalendar? OnBootSec would cause the timers to always run on boot, no matter how much time has passed, which is not what we want. I don't think it is a problem that the timers run on boot, but rather that they delay Type=idle units, like agetty. From what the documentation says, there should not be any delay: Behavior of idle is very similar to simple; however, actual execution of the service binary is delayed until all jobs are dispatched. I am confused why get a delay here. I think another solution in systemd would be introducing a holdoff time: Instead of running immediately on boot, the timer should be scheduled for boot+5min. This requires some investigation - sorry, I don't have a quick solution right now. signature.asc Description: OpenPGP digital signature
Re: [arch-general] svntogit stuck
Am 10.04.2014 06:23, schrieb Kevin Mihelich: Both packages.git and community.git appear to be stuck again, with no updates for the past day. On Fri, Mar 28, 2014 at 2:14 PM, Joel Teichroeb j...@teichroeb.net wrote: packages.git looks fine to me now, but community.git is still stuck. I killed the lock file again, and now the log spits this out. Evangelos, what's going on here? == Updating 'packages' Git repository on Thu Apr 10 11:54:02 UTC 2014 - Fetching changes from SVN git svn rebase command failed; skipping to next repository == Aborted updating 'packages' on Thu Apr 10 11:54:10 UTC 2014 signature.asc Description: OpenPGP digital signature
[arch-general] Linux 3.14-4 to [core]
I am currently uploading Linux 3.14-4 to [testing]. Once signoffs are done, I am planning to move this version to [core]. I'll also move util-linux and coreutils with it. There were no major new bugs I can remember that we didn't fix, so things should be pretty smooth. signature.asc Description: OpenPGP digital signature
Re: [arch-general] /var lost, how reinstal Archlinux?
Am 03.04.2014 11:28, schrieb Martti Kühne: Or better, check with the command that tests all packages' files for presence. # pacman -Qk | grep -v '0 missing files' LOL. Where do you think that information is stored? I'll give you a subtle hint: It's /var. OP is basically screwed. There is no easy way to get his stuff back into working order. There is not even an easy way to determine which packages have been installed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Linux 3.14 in [testing]
Am 02.04.2014 02:51, schrieb Genes Lists: On 04/01/2014 06:44 PM, Thomas Bächler wrote: Okay, pushed everything to [testing] and [community-testing]. This may just be a mirror sync issue but I am seeing this: pacman -Syu ... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: bbswitch: requires linux3.14 :: virtualbox-guest-modules: requires linux3.14 :: virtualbox-host-modules: requires linux3.14 Two problems: 1) findmnt/libmount broken with 3.14 - fixing that now. 2) util-linux/switch_root has problems (this seems like the same issue), see https://bbs.archlinux.org/viewtopic.php?pid=1399663 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Using timers instead of cron jobs
Am 02.04.2014 19:57, schrieb Leonid Isaev: Hi, On a current [testing] installation, there are several timer symlinks in /usr/lib/systemd/system/multi-user.target.wants (shipped with logrotate, man-db, etc.). What is the reason for choosing multi-user.target instead of timers.target? It makes no sense to run these timers in rescue mode. They are supposed to be run only during normal system operation, therefore they are required by multi-user.target. The timer's default dependencies however still require the timers to run before timers.target. signature.asc Description: OpenPGP digital signature
Re: [arch-general] svntogit stuck
Am 28.03.2014 14:29, schrieb Armin K.: In case some of the people responsible for it are reading this: svn2git is stuck for 2 days without any changes although the packages are being upgraded. I can't even examine changes for packages through al.o/packages anymore. It seems the script produced an error, aborted and a lock file stuck around. I removed the lock in the hopes that it will update soon. Thanks fdor the hint. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 28.03.2014 17:11, schrieb Martti Kühne: On Fri, Mar 28, 2014 at 4:03 PM, Bigby James bigby.ja...@crepcran.com wrote: So you think it's justifiable to expect someone you don't know to spend more time than necessary performing a tedious and monotonous task, because maybe, someday, it might make your life slightly more convenient? What if that one day is a year from now? Two years? And what if your time spent experimenting leads you to conclude that these things are factually useless to you? What then of the effort the devs put into it? How did it happen that we're arguing about someone else's effort? Both of us are not trying to tell anyone to do anything, because people know that if they do something they do something and if they don't they don't. Stop standing in the way. You can actually stop arguing about the SELinux issue entirely, since I think I heard all the basic arguments on both sides (if you have something _really_ new to add though, feel free to do so). I'll make up my mind about it and decide how we proceed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
Am 19.03.2014 20:16, schrieb Ary Kleinerman: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages /usr/lib/systemd only contains configuration managed by the package manager and /run/systemd contains only runtime configuration - this is all irrelevant for backups. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
Am 26.03.2014 23:13, schrieb Gesh: Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
Am 27.03.2014 09:41, schrieb Gesh: Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. Not exactly. When you place a unit in foo.wants, then foo gets an additional Wants= dependency. Basically, this is a way to extend units with new Wants= and Requires= statements without modifying unit files. You don't *replace* the dependency graph, but *extend* it. In addition, all unit files are installed to /usr/lib/systemd/system/, Unit files can also be installed to /etc/systemd/system/, for example if you want to use a modified version of a system-supplied unit file. When you run start or enable on a unit name, system looks into those directories, taking the first one it finds. /run/systemd/generator.early /etc/systemd/system /run/systemd/system (*) /run/systemd/generator (*) /usr/lib/systemd/system /run/systemd/generator.late I am not 100% sure if I got the order of the ones marked with (*) right. As you can see here, there are units installed by the package manager (/usr/lib), units installed by the admin (/etc), temporary units installed either by automatic tools or by the admin (/run/systemd/system) and units installed by generators during systemd startup or reload (/run/systemd/generator*). Again, backing up the ones in /usr/lib does not make sense since those are contained in packages and can be reinstalled. Backing up the ones in /run makes no sense either since they only live until you reboot (or reload the configuration, in the case of generator units). However, backing up /etc/systemd/system entirely (not just the symlinks) make lots of sense, since the admin is likely to have custom units in there. and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Not necessarily. For example, /etc/systemd/system/display-manager.service points to /usr/lib/systemd/system/kdm.service. Most symlinks have the same name, but that's only convention, not necesity. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. I'd back up the symlinks including their targets. This makes it easier to restore configuration. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Indeed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
Am 27.03.2014 13:26, schrieb Gesh: But what if bar.unit Wants=foo.unit and I add a custom foo.unit to bar.unit.wants/ ? Will both be run? Will the custom foo.unit replace the built-in? I don't know what happens if you try, but there can only be one unit of the same name. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 09:07, schrieb Nicolas Iooss: I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). I strongly disagree with removing LSM from the packaged kernel. I'm currently using SELinux with AUR packages [1] (which I help to maintain) and a custom policy (basically a mix of Tresys' Reference Policy, Fedora policy and Debian patches [2]) and it works fine. The only reason behind why nobody hasn't asked yet to make libselinux and libsepol official packages? is that before this happens, the current maintainer of these AUR packages wants a working SELinux policy [3]. You use AUR packages for all kinds of SELinux stuff, so why not use a custom kernel for that? Here are three arguments to motivate my disagreement. * First, removing LSM support makes it difficult for users to test LSM. Before 3.13 kernel, users needed to recompile their kernel (or to install linux-selinux AUR package) to be able to use SELinux. So, installing packages from AUR is easy, _except_ when you need to install the kernel? This is a hard first step and I know too many people who thinks I don't want to recompile my kernel as I've already done magical things to make my graphic card works and I don't want to break my fragile config. Now people just needs to install packages (from unofficial repos or from the AUR) as described in the wiki [4] and reboot to start using SELinux. So, install a kernel from unofficial repositories or AUR? It's just a package. * Second, it's possible to compile things which are disabled at runtime. 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 whole idea is to make the kernel smaller and to avoid problems caused by things we don't make use of. Even if they are compiled, they can be enabled/disabled with such runtime configuration and this config doesn't require much work. Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask are we using LSM xyz?. In any case, it's more code and thus more room for failure. I see where you are coming from and I used to think the same way. But after we enabled AppArmor and SELinux in 3.13, the audit subsystem was silently enabled - and it is _on_ by default. This whole story got me thinking, do we even have any idea what the consequences of adding these features are? And I don't think we do. The fact that these LSMs must be compiled into the kernel and cannot be built as modules tells you something important: These options change the behaviour of the kernel at its core. I don't have a really strong argument against these options, except that once we enable them, we need to deal with problems that they may cause users. I think we are better off going with what the majority of Arch users use these days (simple DAC LSM) and let everyone else deal with their use case themselves. * Third, users who want to combine several unofficial features for their kernel already have to do weird things. Users competent enough to do weird things can compile their own kernels. a) Create a linux-light package with less features than the linux package, and don't trim linux' configuration. b) Rename linux as linux-full (as an official package) and trim linux' config. I won't maintain two kernels just for the sake of feature-creep. c) Create a package (linux-src?) which install the kernel sources and provides an easy way to customize the config before making the packages (with pkgbuild). Currently linux-grsec AUR package provides this feature by using the MENUCONFIG environment variable [5]. What is this supposed to do? Makepkg is for building packages, pacman is for installing binaries. If you want automated package building on upgrades, use Gentoo. d) Don't create new packages and trim linux' config (this is your idea, if I understood correctly). signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 15:24, schrieb Simon Brand: Am 27.03.2014 13:46, schrieb Thomas Bächler: Do you even know what that means? If I see this right, every time the kernel needs to do some permission check, it needs to ask are we using LSM xyz?. In any case, it's more code and thus more room for failure. Not necessarily, i do not know the code of all the policy enforcement points, but if you have a function pointer to the policy decision function, you only have to query this function. So if you enable SELinux, you let the pointer point to the SELinux function. Do you know that Linux operates this way? If so, at least we don't have to assume that performance suffers. This again begs the question, why do the LSMs need to be built-in? Why can't they be modular? I don't expect you to answer these questions, they are just things that I consider. Perhaps let me rephrase my rationale: If we include support for an LSM in Linux, it should be because we support it in our user-space, too. I don't see SELinux being supported by default in Arch anytime soon. _If_ at some point we make a decision to support it (optional or by default), we can enable it in the kernel. The whole idea of trimming down the kernel is to stop enabling things because some users _may_ _possibly_ want to use them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 27.03.2014 20:33, schrieb Nicolas Iooss: TL;DR: this is a technical answer which can be seen as slightly off-topic as it focus only on SELinux and not much about kernel config trimming. Very interesting, thanks for looking into it deeper. I'll leave most of this uncommented. This does sound weird. Could you please give me some references to this so that I can understand better? I only know that SELinux uses the audit subsystem to report denials and that the audit subsystem can be disabled at boot time using audit=0 kernel command line parameter (and also I've read http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/audit.c?id=v3.13#n1001). Okay, you are right, it wasn't AppArmor, it was SELinux. According to Kconfig, SELinux depends on Audit. 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. As long as SELinux needs audit and audit is enabled by default, SELinux will not make it to the 3.14+ versions of our linux package. signature.asc Description: OpenPGP digital signature
[arch-general] Trimming down our default kernel configuration
Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without enabling CONFIG_EXPERT. I have no idea what the impact of this option is, other than that it was requested in order to support some tool that can freeze and save single processes resume them later. I am generally sceptical towards options that require CONFIG_EXPERT, so I propose dropping this one, too. 3) We enable tons of debug options in the Kernel Hacking section, many of which have a small performance impact. I'd like to get rid of those that we don't need (I didn't go through all of them yet). What I'd like is a discussion where people suggest more things that could or should be dropped, and tell me what is absolutely needed and why. I hope that such a discussion makes it clearer to me how I should proceed. Regards Thomas signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 26.03.2014 20:18, schrieb Leonid Isaev: However, I don't think that Yama requires any userspace components, does it? Currently, I boot with security=yama and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Error when I try update pacman -Syu
Am 24.03.2014 17:18, schrieb Karol Blazewicz: jre7 is in the AUR so pacman won't update it, but jre7-openjdk is in the repos and provides the same 'item' as jre7: java-runtime=7 https://aur.archlinux.org/packages/jr/jre7/PKGBUILD https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/ that's why they conflict. That's not why they conflict. It's because jre7 explicitly has java-runtime=7 as a conflict (among others). 'conflicts' has nothing to do with 'provides'. You seem to be using jre7. If you want to keep using it, you have to keep jre7-openjdk out. Try adding it to IgnorePkg. And how will that help? root@arch-maykel /home/maykel/ # LANG=C yaourt -Rdd jre7-openjdk error: target not found: jre7-openjdk It seems that a package is updated and the newer version explicitly depends on jre7-openjdk. This is probably a packaging error (although after a quick glance at the repos, I cannot find any such package). signature.asc Description: OpenPGP digital signature
Re: [arch-general] Connect android with kdeconnect in archlinux
Am 20.03.2014 13:11, schrieb Maykel Franco: I have installed kdeconnect by pacman. When I exec: maykel@arch-maykel ~/ $ sudo qdbus org.kde.kded /kded loadModule kdeconnect qdbus: could not exec '/usr/lib/qt/bin/qdbus': No such file or directory Can I help me please? 1) Either use qdbus-qt4 or configure the default version properly in /etc/xdg/qtchooser/. 2) What drives you to use sudo for this command? It makes no sense whatsoever. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Connect android with kdeconnect in archlinux
Am 20.03.2014 13:20, schrieb Maykel Franco: root@arch-maykel /home/maykel/ # qdbus org.kde.kded /kded loadModule kdeconnect I hate to repeat myself, but WHY? signature.asc Description: OpenPGP digital signature
Re: [arch-general] problem booting and using the installation media
Am 14.03.2014 20:52, schrieb LANGLOIS Olivier PIS -EXT: I am trying to boot the installation media on a small embedded system already running linux. Everything boots fine until udev starts loading modules. Approximately when the install media reach the bash prompt, the display gets garbled. I suspect that this is when the graphic mode switch from text to graphic. Try booting with the 'nomodeset' option on the command line. The graphic chipset on this system is: 00:02.0 VGA compatible controller [0300]: Intel Corporation System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108] (rev 07) Poulsbo is crap, and the driver is probably barely tested. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Am 11.03.2014 11:52, schrieb Manuel Reimer: Jelle van der Waa jelle at vdwaa.nl writes: FYI: https://mailman.archlinux.org/pipermail/arch-dev-public/2014- March/025952.html Thank you for this information. Am I allowed to ask gmane.org to add this list to their archive? This would really help me to get access to this list. I am not sure if gmane needs our permission for that, since the list is public. However, posting to the list requires subscription (as for all our lists), so the gmane copy will be read-only. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Am 11.03.2014 11:55, schrieb Thomas Bächler: Am 11.03.2014 11:52, schrieb Manuel Reimer: Jelle van der Waa jelle at vdwaa.nl writes: FYI: https://mailman.archlinux.org/pipermail/arch-dev-public/2014- March/025952.html Thank you for this information. Am I allowed to ask gmane.org to add this list to their archive? This would really help me to get access to this list. I am not sure if gmane needs our permission for that, since the list is public. However, posting to the list requires subscription (as for all our lists), so the gmane copy will be read-only. I quickly went over to gmane and requested subscription of arch-security to gmane, so there is nothing left but to wait. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Security vulnerability (CVE-2014-0004) in udisks/udisks2
Am 11.03.2014 12:02, schrieb Manuel Reimer: Thomas Bächler thomas at archlinux.org writes: I quickly went over to gmane and requested subscription of arch-security to gmane, so there is nothing left but to wait. I hope you didn't request readonly as, if I'm registered to the list with the mail address, I use from the gmane webinterface, it is possible to post to, for example, the general list. This posting is written using the gmane webinterface and in many cases I don't have access to my private mail, so having access to a list via webinterface can be very handy. I think I did. I didn't know you could post to the list when you're subscribed. I guess I'll try to change the options again when I hear back from them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problems of using pacman and updating the filesystem
Am 07.03.2014 07:06, schrieb Cao, Renzhi (MU-Student): After this, I use the following command to update the system: pacman -Syu --ignore filesystem,bash pacman -S bash and then reboot, get the following information: And why didn't you complete the instructions by running 'pacman -Su' before rebooting? Now you broke it, and you need to fix it with a live system. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problems of using pacman and updating the filesystem
Am 07.03.2014 15:51, schrieb Caorenzhi: Yes, I try pacman -Su, and they said the /usr/sbin is exists. I am thinking that is ok, so I reboot the system. The instructions explicitly stated that this is NOT okay. I have a cd to load the system, and I have another computer to download packages and have a external hard disk to use, like copy files there. Is there still any way to solve my problem? Sure there is. Boot from a recent Arch Linux live CD, mount your file systems to /mnt and run arch-chroot /mnt /usr/bin/bash Then make sure there are no files left in /usr/sbin, /sbin and /usr/bin - most likely, you need to uninstall a package that you built yourself - you can properly rebuild it later and install it again. Or you need to uninstall a package that used to be part of Arch, but it no longer needed. When you are done, pacman -Su should work flawlessly (the package is already in your cache, so no network is required). To be safe, run 'mkinitcpio -P' so your system boots correctly. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problems of using pacman and updating the filesystem
Am 07.03.2014 16:09, schrieb Caorenzhi: Do I also need to remove files in /usr/bin as you said? Or you mean /usr/sbin, /sbin, /bin? You are right, only files in /bin, /sbin and /usr/sbin should be gone. Everything should be in /usr/bin after the update. Since that is what I see the error from at beginning. There are a lot of files in /sbin, should I remove all of them? You should find out which packages they belong to and either uninstall or fix those packages! signature.asc Description: OpenPGP digital signature
Re: [arch-general] bridge with netctl
Am 06.03.2014 14:03, schrieb arnaud gaboury:
Dear list,
I am running a machine hortensia with a container dahlia. As the
container will be a server, I want to have one IP for hortensia and
another one for dahlia.
On hortensia, with dhcpcd.service and systemd-networkd both disabled,
I start at boot two netctl profiles.
/etc/netctl/bridge-hortensia
Description=Bridge connection to container
Interface=br0
Connection=bridge
BindsToInterfaces=()
IP=no
/etc/netctl/static-hortensia
Description='hortensia static ethernet connection'
Interface=enp7s0
Connection=ethernet
IP=static
Address=('192.168.1.87/24')
Gateway=('192.168.1.254')
DNS=('192.168.1.254')
This configuration make no sense whatsoever.
1) You create a bridge with no ports. What purpose does it serve?
2) If you want to add enp7s0 as a port, why do you have a configuration
for enp7s0? If an interface is a bridge port, it cannot be used for IP
traffic, so assigning it an IP is pointless.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] bridge with netctl
Am 06.03.2014 16:19, schrieb Paul Gideon Dann: If I understand correctly, in fact I took the set up upside down. I tried br0 --- enp7s0 when in fact the scheme is |- dev 1 enp7s0 bridge br0 | |-- dev 2 Am I correct in this scheme? What do you mean by dev 1 and dev 2? Independently of what dev1 and dev2 are, the answer is 'no'. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Network-Issues after last updates
Am 05.03.2014 12:26, schrieb Ruben Kelevra: I still using netcfg to staticly configure my cards, the only hw-card was eth0 and now named ens3, which was the first problem on that upgrade ... changing eth0 to ens3 in configuration still wont fix the problem... Old installations still had interface renaming disabled by default (on Arch). This got lost on the overhaul of the network interface handling in udev. I'm now upgrading to networkd or netctl, but since I'm not the only in IRC which got the problem you might consider to send out a warning for this might happen. netcfg can fail for various reasons when used with systemd - don't use it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] A bug report when installing bbswith, depmod:ERROR
Am 05.03.2014 12:39, schrieb Felix Yan: On Wednesday, March 05, 2014 19:36:28 Liuyang wrote: depmod: ERROR: Module 'hci_vhci' has devname (vhci) but lacks major and minor information. Ignoring I got the message above after I update my system to the newest released version. Then bbswith and bumblebee doesn't work now. I tried to reinstall that two packages but it still reported the bug message. What can I do? PS: Forgive my pool English. Please at least search on our bug tracker first. Here's the link: https://bugs.archlinux.org/task/38686 It's funny how people get the idea that this bug report has anything to do with bbswitch not working. Yet, there is no bug report open regarding any problems with bbswitch. If you have a problem, open a bug report describing *your problem*. Do not hijack an entirely unrelated bug report that you *think* may be related. If your problem turns out to be related, a bug wrangler or developer can take appropriate action. signature.asc Description: OpenPGP digital signature
Re: [arch-general] A bug report when installing bbswith, depmod:ERROR
Am 05.03.2014 16:07, schrieb Felix Yan: It's funny how people get the idea that this bug report has anything to do with bbswitch not working. Yet, there is no bug report open regarding any problems with bbswitch. Hmm, sorry for not reading the original mail in full. I pasted the link just for the depmod message part, and totally missed the point that OP was trying to diagnose his bbswitch just as those on the bug report... I have grown so tired of these reports that I am actually going to fix this problem in our kernel, in order to restore my sanity. What a waste of compile time. signature.asc Description: OpenPGP digital signature
Re: [arch-general] ppp 2.4.6 in testing breaks pptp connections in NetworkManager
Am 23.02.2014 08:42, schrieb Savyasachee Jha: Whenever I try connecting to my university's VPN, the authentication fails. Running systemctl status NetworkManager gives me the message: Feb 23 16:06:06 Empire NetworkManager[285]: info Starting VPN service 'pptp'... Feb 23 16:06:06 Empire NetworkManager[285]: info VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 946 Feb 23 16:06:06 Empire NetworkManager[285]: info VPN service 'pptp' appeared; activating connections Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state changed: starting (3) Feb 23 16:06:06 Empire NetworkManager[285]: info VPN connection 'KUINS' (Connect) reply received. Feb 23 16:06:06 Empire pppd[947]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so is for pppd version 2.4.5, this is 2.4.6 Feb 23 16:06:06 Empire NetworkManager[285]: warn VPN plugin failed: 0 Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state changed: stopped (6) Feb 23 16:06:06 Empire NetworkManager[285]: info VPN plugin state change reason: 10 I went to /usr/lib/pppd and found 2 folders, 2.4.5 and 2.4.6. Should I recompile networkmanager-pptp and pptpclient? The networkmanager, networkmanager-pptp and pppd-ldap-simple packages should probably be recompiled. extra/networkmanager 0.9.8.8-1 /usr/lib/pppd/2.4.5/nm-pppd-plugin.so extra/networkmanager-pptp 0.9.8.4-1 /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so community/pppd-ldap-simple 0.12b-6 /usr/lib/pppd/2.4.5/pppd_ldap_simple.so (Good thing that anyone actually uses testing/ppp to notice these problems.) signature.asc Description: OpenPGP digital signature
Re: [arch-general] ppp 2.4.6 in testing breaks pptp connections in NetworkManager
Am 23.02.2014 11:05, schrieb Savyasachee Jha: I downgraded for the moment, though thanks. Will the affected packages be recompiled in testing This will be done shortly. signature.asc Description: OpenPGP digital signature
Re: [arch-general] ppp 2.4.6 in testing breaks pptp connections in NetworkManager
Am 23.02.2014 11:07, schrieb Savyasachee Jha: Thank you very much. -- Savyasachee Jha Sent from my Nexus 5 On Feb 23, 2014 7:06 PM, Thomas Bächler tho...@archlinux.org wrote: Am 23.02.2014 11:05, schrieb Savyasachee Jha: I downgraded for the moment, though thanks. Will the affected packages be recompiled in testing This will be done shortly. Done. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] ppp 2.4.6 in testing breaks pptp connections in NetworkManager
Am 23.02.2014 12:53, schrieb Arthur Țițeică: I've seen these issues but I didn't have enough time to come to a sane conclusion in order to report it. IIRC rp-pppoe in core has the same problem. pppd[27117]: Plugin /usr/lib/rp-pppoe/rp-pppoe.so is for pppd version 2.4.5, this is 2.4.6 Bug report at: https://bugs.archlinux.org/task/39007 Since that plugin is not even in the pppd plugin path, there is no way to detect this problem. Besides rp-pppoe, pppd-ldap also needs a rebuild (the plugin is still for 2.4.4, so I wonder if a single person ever used it). I also wonder why rp-pppoe is still in core. It provides no essential functionality that netctl+ppp don't. signature.asc Description: OpenPGP digital signature
Re: [arch-general] NetworkManager 0.9.8.8-2 does not work with systemd 208
FWIW, Jan already fixed the problem. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] systemd 209 in [testing]
Am 21.02.2014 17:16, schrieb Genes Lists: My /etc/systemd/logind.conf has this: HandleLidSwitch=ignore LidSwitchIgnoreInhibited=no This would require your desktop (KDE for example) to react on the LID closing. which USED to be required - I now wonder if this should be changed to: HandleLidSwitch=suspend LidSwitchIgnoreInhibited=no This means that logind will initiate a suspend on LID closed *except* when something inhibits it - for example, KDE inhibits logind from suspending. signature.asc Description: OpenPGP digital signature
[arch-general] Linux 3.13 status
Okay, it's been way too long. I don't really have the time to spend much time on the kernel right now, and neither does Tobias, so it's been sitting in [testing] for way too long. I am currently building 3.13.3-2 with a critical NFS fix and I intend to move that kernel to [core] very soon. Due to the keyboard changes, I'd like to make the following announcement: Linux 3.13 WARNING: PS/2 Keyboard support is now modular It has been requested that we make support for the i8042 keyboard and mouse controller modular. Some people get weird error messages because they don't have one and the manual probing slows down their boot. Tom took care of this on the kernel side (thank you) and the result finally landed in 3.13. In order to get keyboard input during early init, if you don't have it already, add the `keyboard` hook to the `HOOKS=` line in `/etc/mkinitcpio.conf`. It has been in the default configuration for some time. **WARNING**: There's a downside to all this: On some motherboards (mostly ancient ones, but also a few new ones), the i8042 controller cannot be automatically detected. It's rare, but some people will surely be without keyboard. You can detect this situation in advance: $ dmesg -t | grep ^i8042 i8042: PNP: No PS/2 controller found. Probing ports directly. If you have a PS/2 port and get this message, add `atkbd` to the `MODULES=` line in `mkinitcpio.conf` and run `mkinitcpio -P`. If you just noticed that you are without keyboard after rebooting, fear not! Simply add earlymodules=atkbd modules-load=atkbd to your kernel command line in your bootloader. I apologize for any inconvenience this transition may cause. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Updating the archlinux-keyring package
Am 14.02.2014 12:43, schrieb Don deJuan: wouldn't is make more sense to have a systemd timer/cron job to frequently refresh pacman keyring? pacman-key --refresh-keys ?? If you are paranoid enough that a former Arch developer or TU will be able to inject a broken package into a mirror, then it certainly helps you to run 'pacman-key --refresh-keys' regularly. You can also do so on the live CD. This will not automatically add new keys, but certainly remove trust from revoked keys. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Systemd email notifications
Am 13.02.2014 13:04, schrieb Paul Gideon Dann: Does anyone know of any standard system for receiving notifications from systemd for unit state changes? I currently use Monit for the monitoring of many processes, and it'll e-mail me when things happen (e.g. a process was restarted). Since switching to systemd, it's felt a bit silly that for several processes, I'm having Monit monitor them simply because systemd is unable to tell me it restarted a unit. Monit isn't actually required to keep those processes alive as it once was, because systemd can do that. I'd place a bet on the systemd dbus API: IIRC, it exports the state of each unit as a property and then emits the standard org.freedesktop.DBus.Properties.PropertiesChanged signal when the state changes. So, your task would be to subscribe to that signal and act on it. This could be nicely done in python (and maybe someone has done it already). I just listed some properties using qdbus: $ qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/dbus_2eservice org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Unit ActiveState active $ qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/dbus_2eservice org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Unit SubState running $ qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/dbus_2eservice org.freedesktop.DBus.Properties.Get org.freedesktop.systemd1.Service MainPID 391 Surely, the ActiveState, SubState and MainPID properties would change when something gets restarted or stopped, and you would receive the PropertiesChanged signal. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Systemd email notifications
Am 13.02.2014 16:05, schrieb Rodrigo Rivas: Ok... I'll take the chance to practice my DBus abilities... It is a bit long, but it kind of works. Just replace the print() call with your favourite sendmail function and you'll get a notification every time any of the units specified in the command line changes status. This isn't too long and it actually seems to work fine. I guess what Paul actually wants is a system where you would subscribe to all services, not just some of them. This should be possible as well with the API. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Forum registration requires INSANE captcha.
Am 10.02.2014 15:42, schrieb Feliz Xett: On the bottom of the registration page there was a very clever captcha. The question was: What is the output of date -u +%V$(uname)|sha256sum|sed 's/\W//g'? I might even have found this funny if I wasn't ON A NON-LINUX LAPTOP. By reading manpages (readily available on the internet), an online sha256 calculator and some brain function, you can easily solve this without a Linux computer. (I just solved it with some online calculator, just make sure to add a newline, I forgot it at first, and it leads to a wrong result.) Why is there not just a simple normal captcha that helps Google with house numbers or something. Because I (and many others) find those captchas to be mostly unreadable and impossible to solve (unless by use of a computer). (It was not me who came up with or implemented this method, but I find it funny and entertaining, while usual captchas drive me nuts. I usually leave a website instantly when I have to solve a captcha for anything.) It looks to me like someone wanted to demonstrate that whoever is not able to find the solution to *such* a simple question is not worthy of the forums. I dare say you are right about that. It keeps away lots of trolls. Also, this is obviously absolutely unsuitable to tell computers and humans apart (if that's what was intended), considering that the result only changes once a week and any unix machine could easily calculate the result. There are no bots programmed to solve this special problem, or read the special question on the Arch bbs. On the other hand, there are many bots programmed to solve every captcha system there is. In that regard, it is a practical solution to keep bots away - until someone is eager to attack specifially the Arch bbs. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Permanently allow root access
Am 01.02.2014 04:55, schrieb piruthiviraj natarajan: I want to run root X application in a terminal. [root@archbox ~]# smplayer smplayer: cannot connect to X server [root@archbox ~]# I followed the wiki https://wiki.archlinux.org/index.php/Running_X_apps_as_root Again, the most convenient method of doing this is not included in the wiki. Add the line session optionalpam_xauth.so to /etc/pam.d/su and /etc/pam.d/su-l. Then switch to your root user using 'su' or 'su -'. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Permanently allow root access
Am 01.02.2014 10:06, schrieb piruthiviraj natarajan: On Sat, Feb 1, 2014 at 2:22 PM, Thomas Bächler tho...@archlinux.org wrote: Again, the most convenient method of doing this is not included in the wiki. Add the line session optionalpam_xauth.so to /etc/pam.d/su and /etc/pam.d/su-l. Then switch to your root user using 'su' or 'su -'. How is this inconvenient? I don't get it. Your method worked and it can't be any easier. Thank you so much. All the methods in the wiki are inconvenient, this one is - on the contrary - extremely convenient. signature.asc Description: OpenPGP digital signature
Re: [arch-general] journalctl and I/O errors
Am 30.01.2014 11:46, schrieb Nowaker: If it's possible to read the file, journalctl should not segfault IMO, so it should be OK to file an issue. No program should ever segfault. Unexpected input or errors must be handled properly. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Kernel 3.13
Am 28.01.2014 09:07, schrieb David C. Rankin: Yes, and I am still unclear what is required to insure that an appropriate module is loaded for a normal laptop/desktop. Nothing. The keyboard should simply. I already include 'keyboard' in HOOKS This is only required if you want to use the keyboard in early userspace, which 90% of the time, you don't even have to (encrypted root is one popular exception, handling a failsafe shell is another). The 'keyboard' hook has been in the defaullt configuration for a a while now. I vote for a solution that insures a keyboard is always probed/detected/provided If your keyboard doesn't work out of the box with 3.13-2, please add a comment to the appropriate bug report [1] (that is for everyone - comment on that bug if you have keyboard problems with 3.13-2). Everything else is just a waste of time. [1] https://bugs.archlinux.org/task/38671 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Howto setup i686 archroot on x86_64 box? (not linux32 chroot)
Am 25.01.2014 07:25, schrieb David C. Rankin: I use the Classic Way of handling the build specified in https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot. If you use devtools anyway (which you definitely should when building a packages for more than one computer), simply run 'sudo extra-x86_64-build sudo extra-i686-build' in the PKGBUILD directory. There's not much more to do. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Mirrors out of date
Am 15.01.2014 17:15, schrieb Simon Gomizelj: The check script runs on a regular basis and polls for the lastsync file in the root of our repository layout. This file is regularly updated on the central repository, so checking the value within allows one to see if the mirror has synced recently. There is a file called lastsync. It is read http://mirror.csclub.uwaterloo.ca/archlinux/lastsync Try: date -d @$(curl http://mirror.csclub.uwaterloo.ca/archlinux/lastsync 2/dev/null) signature.asc Description: OpenPGP digital signature
Re: [arch-general] LUKS emergency self-destruct
Am 13.01.2014 11:57, schrieb Paladin: Patch is for 1.6.1 but it cannot be that difficult to port it to 1.6.3 which we have. This feature has already been rejected by the cryptsetup authors as far as I can see. So no, we will not keep maintaining our own cryptsetup modification. signature.asc Description: OpenPGP digital signature
Re: [arch-general] libgcrypt.so.20 missing
Am 13.01.2014 19:33, schrieb Mark E. Lee: However, I suggest an announcement on the website regarding this problem. No. I had three issues when trying to solve this problem: 1) the mirror I was using wasn't up to date (still had libgcrypt-1.5.3-1) You see, that is impossible. The package database contains either both the old pth and old libgcrypt, or both the new pth and new libgcrypt. 3) Failure to update libgcrypt before other packages resulted in a kernel that seemed to be hung at booting. Sorry, I can't see how that would be related in any way. signature.asc Description: OpenPGP digital signature
Re: [arch-general] systemd claims /run out of space
Am 13.01.2014 17:54, schrieb Jameson: For some reason on my home server, systemd is often telling me I'm out of space, but I can't find a problem. Just now, I stopped httpd, and when I try to start it, again, systemd says I'm out of space, the status reports: systemd[1]: Failed to set a watch for httpd.service's PID file /run/httpd/httpd.pid: No space left on device. That error message is confusing. The inotify_add_watch() system call returns ENOSPC. Usually, ENOSPC means No space left on device, and the strerror() library call translates it to that. However, in the context of inotify_add_watch(), it means: ENOSPC The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource. So, it seems that you allocated many many inotify watches and need to increase the limit. signature.asc Description: OpenPGP digital signature
Re: [arch-general] libgcrypt.so.20 missing
Am 13.01.2014 20:34, schrieb Mark Lee: On Mon, 2014-01-13 at 14:19 -0500, Mark Lee wrote: The reason why packages couldn't upgrade was because of gnupg which is needed for package signature verification from pacman. An updated gnupg points to libgcrypt.so.20 while the old one points to libgcrypt.so.11. Hence, what has to be done is gnupg must be updated before libgcrypt (or else signature verification fails). Libgcrypt must be updated before the system is rebooted or else gnupg fails. Hence, an advisory should be sent out that gnupg should be updated before libgcrypt, and libgcrypt should be updated before the system's ever rebooted. Salutations, Actually scratch that, one should install gnupg 2.0.22-2 and libgcrypt 1.6.0-1 simultaneously (same pacman line) before trying to install other things. That is all nonsense. Everything must be updated in a single transaction using `pacman -Syu`. This has been done by countless [testing] users in December without a single reported problem. signature.asc Description: OpenPGP digital signature
Re: [arch-general] libgcrypt.so.20 missing
Am 13.01.2014 22:48, schrieb Mark Lee: Salutations, All right then; if it works for you guys. Will an announcement be made on the arch website to ensure the upgrade doesn't break more systems or will we continue the wait game and hope that all the mirrors sync and the issue just goes away? As Lukas pointed out by now, a mistake was made when moving the packages, and libgcrypt was moved 20 minutes after the rest of the packages. Any mirror that synced in that timeframe will have an inconsistent state. There is no point in announcing anything, since all mirrors should have the corrected files already, and whoever didn't break their systems by now won't break them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] systemd claims /run out of space
Am 14.01.2014 00:35, schrieb Jameson: Thanks, man. You nailed it. Do you think I should file a bug report somewhere to see if I can have the devs work out a better error message? Is it a kernel bug, a bug with the strerror library, or a systemd issue? It is in the function service_watch_pid_file here: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/service.c#n2783 I guess systemd shouldn't blindly print the strerror message and provide a better one. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Default value of j in makeflags of makepkg.conf
Am 03.01.2014 15:03, schrieb Øyvind Heggstad: You are suggesting not changing to a sane default because some packages (especially in the AUR) have crappy maintainers. That's hardly a reason for anything. Your defenition of sane default might not match someone elses. Many people prefer their box to not slow to a crawl just because they started makepkg :) Again, we're not changing to a sane default because some people are unable to use their machines properly? 'nice' works just fine, and I haven't seen machines slow down due to compiling even without it - the Linux scheduler handles many simultaneous workloads just fine. signature.asc Description: OpenPGP digital signature
Re: [arch-general] USB S-ATA Adapter
Am 03.01.2014 15:02, schrieb Silvio Siefke: Hello, my Notebook is broken and so i buy a Adapter that i can take my Data from the Harddisk. siefke ~ $ lsusb Bus 001 Device 003: ID 0402:9665 ALi Corp. Gateway Webcam Bus 001 Device 004: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3 siefke ~ $ ls /dev | grep sd sda sda1 sda2 sdb SDB is the HDD but i can not mount and fdisk give nothing out. fdisk -l /dev/sdb blkid /dev/sdb signature.asc Description: OpenPGP digital signature
Re: [arch-general] Default value of j in makeflags of makepkg.conf
Am 03.01.2014 15:21, schrieb Martti Kühne: You can't expect every upstream to fix their autohell to conform to our expectations here. So, we keep repeating ourselves. There is the !makeflags option for PKGBUILDs to work around this problem (which you would know if you read the thread). If a package is broken with -j, this option helps. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Default value of j in makeflags of makepkg.conf
Am 03.01.2014 15:33, schrieb Martti Kühne: On Fri, Jan 3, 2014 at 3:23 PM, Thomas Bächler tho...@archlinux.org wrote: Am 03.01.2014 15:21, schrieb Martti Kühne: You can't expect every upstream to fix their autohell to conform to our expectations here. So, we keep repeating ourselves. Because I have a strong opinion about this. Also to prevent people from running into this who are not that experienced in making things work. If you are not experienced, you should think about your operating system choice. We are not a kindergarten, we are a distribution with a target audience of experienced and advanced users.x There is the !makeflags option for PKGBUILDs to work around this problem (which you would know if you read the thread). If a package is broken with -j, this option helps. It's not nice to introduce this, then people start packaging some new piece of software they want to throw on the aur, If it were my choice, we would enforce high quality standards for the AUR (which would likely force us to delete 90% of PKGBUILDs from it). If you just want to throw a piece of software on the AUR without checking the PKGBUILD for compliance with expected quality standards and correctness, then fuck you. I will not stand by while we encourage people to continue to produce low-quality bullshit and upload it to the AUR. but which no one cared to build with -j yet and they would check their build trees again and again and spent amounts of time on this similar to me to figure out what was going on - all while a manual build just worked for them. All I hear is whining because you were unaware of a very common issue. As a package maintainer or AUR maintainer, it is your duty to test whether the build causes problems with -j (and you don't even need a multi-core machine to do that). Garbage error messages, huge autohell pains, and all because of mr. brain0. So, now I am responsible for every low-quality piece of shit software that is being published. You are giving me way too much credit. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Default value of j in makeflags of makepkg.conf
Am 03.01.2014 16:11, schrieb Paul Gideon Dann: If it were my choice, we would enforce high quality standards for the AUR (which would likely force us to delete 90% of PKGBUILDs from it). Sounds like a barrel of laughs! When I look at the AUR sometimes, I don't laugh - I cry. The current state of the AUR makes Arch Linux look like a very bad joke. So just to get this straight: if someone's going to become a packager, they need to learn how to do it *instantly*. They should first learn it, and then start uploading to the AUR. In particular, you should not upload to the AUR instantly. There should be no margin for error and inexperience. Error and inexperience can occur while learning. If you upload to the AUR, I expect you to have polished and finished material, not your first draft. There's enough places with kind people who will look at your PKGBUILD and point out your mistakes. The AUR isn't one of those places. signature.asc Description: OpenPGP digital signature
Re: [arch-general] libpng 1.6.7 broken?
Am 03.12.2013 12:19, schrieb Simon Perry: | I think you have three possibilities: | | * The image is not generated dynamically but stored in a database. Simply | update the image with the fixed one. Why? Because 1.6.7 can't handle older files? IIRC, newer libpng versions refuse to handle some broken PNG files which do not follow the PNG specification. The files are broken, not the PNG interpreter - there has been a discussion about this a long time back. Of course, it might still be a bug in the latest libpng and the PNG files are alright. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Initramfs fallback render
Am 15.11.2013 15:55, schrieb Anatol Pomozov: The correct way to disable root completely is to make it expired usermod --expiredate DATE_IN_PAST root. I tried it on my machine and found that pacman is broken. I believe it uses su before running install scripts. Nothing about disabling the root account is correct. If you disable the account, both 'su' and 'sudo' cannot function. You _need_ the root account. signature.asc Description: OpenPGP digital signature
Re: [arch-general] LVM + mdadm no longer works on boot
Am 22.10.2013 05:46, schrieb Sean Greenslade: On Mon, Oct 21, 2013 at 02:55:20PM +0200, Thomas Bächler wrote: Am 21.10.2013 03:34, schrieb Sean Greenslade: And now, after another system update, the problem has vanished. There was a kernel update, so I'm willing to believe that it was just some strange transient interaction between LVM, mdadm and the initramfs kernel. Just another day in the life of Arch, I suppose. This is confusing. A common problem is that the mkinitcpio image is generated mid-upgrade. If some component of lvm is updated before the kernel and another is upgraded after, this may lead to broken images. We can't prevent this from happening right now, but OTOH I haven't seen it in a while. To be on the safe side, run 'mkinitcpio -P' after kernel updates. That would make sense. I didn't try enough downgrade-upgrade cycles to test that theory. I'll add that to the list of things to do when updating. For the future, pacman hooks ([1]) may solve that problem without user interaction, but as far as I know nothing has been implemented yet. [1] https://wiki.archlinux.org/index.php?title=User:Allan/Pacman_Hooks signature.asc Description: OpenPGP digital signature
Re: [arch-general] LVM + mdadm no longer works on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 21.10.2013 03:34, schrieb Sean Greenslade: And now, after another system update, the problem has vanished. There was a kernel update, so I'm willing to believe that it was just some strange transient interaction between LVM, mdadm and the initramfs kernel. Just another day in the life of Arch, I suppose. This is confusing. A common problem is that the mkinitcpio image is generated mid-upgrade. If some component of lvm is updated before the kernel and another is upgraded after, this may lead to broken images. We can't prevent this from happening right now, but OTOH I haven't seen it in a while. To be on the safe side, run 'mkinitcpio -P' after kernel updates. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSZSQ4AAoJEChPw0yOSxolJBgP/3myZ6eNdLNZWBOIOKwGbjHF 38dwGkg6hlM8CaPvPsBvBJq6z9q7NFIYFLAiGSYeq3Im3MxQs0usFvC6hdMY0prV L4IsLd48Tma/sTgPwfgxv37GibAcJUb4a+hiWB2Cg1WFEQMPV93YTR01QV08FPFA ELpSpsIJLzctmeN0Y9uHbkFpJgdC1UgnkAuJ6mV9qlIZKNDGcHavnyyRtat9ZPUW VrhrieKER5ug4GDdj8ofLATJP3W+0cIHFPXy6kkNE6gGVD4wpIPBJh5XBuV6XNTD prBdX3Y5zggLh0p+UR5RV6cDFy8Kd0VW7BVEzm16xuFZn/Gln5UrA4gpt7Nl2+Tx cSQzpwHT9ro4asxfMoZkVMNzATRelBZTyuSAhVVjhdFXGW/q59BVMJTRzViKzZRh JkVi5eG8ACvjx1bkI6qTZ7zeZ1PtA8PdUAYQLFbcZSh0jd1DxNrQOlU2+VSwxx9u 3RsEFgx6PKdEEW2GFpIlgzXFmS1EpuKg0/q0tilwkxo4gdVxE8DCnaHc1cYJvTAn IallrzriD7vkVEcBDBR2d6wXuImMPz+GUAx4h/Q+tMmNMaaw2IgVfdOPD4AuFqec PyxeWGe7X5RAFOW/ZuVVQLR6RKXKQQXwEW9AVW+BmMowfrZP/2gt8qSE2krCT0EJ yQ5V5UsXf1BO/548wbKA =TNxu -END PGP SIGNATURE-
Re: [arch-general] LVM + mdadm no longer works on boot
Am 15.10.2013 21:37, schrieb Sean Greenslade: Hi, all. I'm running a small fileserver that has three SATA drives set up in RAID5 via mdadm. That RAID holds one LVM pv which is split up into several logical volumes. This setup has worked fine in the past, but with the lastest system update my LVM partitions are not getting discovered correctly, leading to the boot hanging until I manually run vgchange -ay. After that, the boot proceeds as normal. It would appear that the latest lvm2 package is what causes the issue. Downgrading to 2.02.100-1 boots fine, whereas 2.02.103-1 hangs. So how exactly should I proceed from here? I'm trying to understand how systemd makes it all work together, but I'm rather confused by it all. Are you assembling RAID and LVM in initrd? If so, what's your HOOKS line in mkinitcpio.conf? I've seen reports like this before (although most people said they were fixed with updates and had problems before 2.02.100). Sadly, I could never reproduce it, so I don't know how to debug it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Fwd: Proposal for the static library problem in Arch
Am 28.09.2013 16:26, schrieb Delcypher: I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro This has been discussed more than once, always with the same result. Static libraries are a dead end and are going away. signature.asc Description: OpenPGP digital signature
Re: [arch-general] glibc 2.18-5 question
Am 27.09.2013 14:56, schrieb Chris Down: Well, static libraries are not a waste of space if it was intentional. Static linking should be preferred for a number of reasons[0], they should be preferred in any sane Linux distribution (of which, unfortunately I can't name any at the moment until stali comes out). 0: http://sta.li/faq Nothing about using static libraries is sane. That FAQ seems to be about some bitterness about glibc and its code, which has nothing to do with static and dynamic linking. Now, to the key point: Aren’t statically linked executables less secure? Several people argue (with implicitly requiring ABI-stability) that dynamically linked executables benefit from security fixes in libraries they depend on. What some people argue is true. If there is a vulnerability in zlib (which actually happened a few years back), all that is needed is to rebuild zlib and be happy. A statically linked system would need to find every single binary that incorporates zlib and rebuild it. This is true to some extend, but if there is a security flaw in a dynamically linked library, all programs are affected as well; whereas statically executables aren’t. This is the biggest pile of nonsense I ever read. If there is a flaw in a library, all programs that use it are affected - including statically linked executables that were built using that library. It is even worse: There is no easy way to determine which version of the library a specific binary was built against. This is a security nightmare. We know that there is some overhead in re-compiling all affected executables if a dependent library is insecure, but we don’t see this as a critical disadvantage, because we also focus on a small and maintainable userland, where only one tool for each task exists. On a system like Arch that includes a several desktop environments, web servers, web browsers, ... (tons of other stuff), that statement is simply nonsense. In the 1970s, you would call the 'gzip' (or even 'decompress') binary to decompress a file, but in the year 2013, you use a library API for that because it is more convenient, less error-prone and more efficient. The 'one tool for each task' has long become 'one implementation for each task', but that implementation is no longer in a binary, but in a shared/static library. If you really insist on the old way of doing things, you will be unable to use any modern program because they don't follow the old 'one tool' paradigm anymore, they don't call external programs. As an Arch user, you would first have to rewrite pacman to not use libarchive, but to use xz, gzip and tar to handle packages and package databases. After you've done that, you can start talking about statically linking those tools - but at that point, pacman will already be too slow to be usable in any way. signature.asc Description: OpenPGP digital signature
Re: [arch-general] glibc 2.18-5 question
Am 27.09.2013 16:10, schrieb Chris Down: That FAQ seems to be about some bitterness about glibc and its code, which has nothing to do with static and dynamic linking. Not really. The releated references to glibc are more about refuting the size argument when linking against it (as opposed to a more sane libc). In his 'Aren’t statically linked executables huge?' section, he wants to say that statically linked binaries are not as big as people think. For that, he compares two binaries of ksh: Static uclibc: 170KB Dynamic glibc: 234KB This comparison is entirely worthless. glibc is not optimized for size and has lots of overhead (as he correctly states). Compile and link the same code dynamically against uclibc and you will get something in the tens of kilobytes. I use OpenWRT on an embedded device, and they use uclibc and dynamically linked libraries/binaries everywhere - the size difference to statically linked binaries is incredibly huge here, to the point that using static linking will result in a firmware image too large to even flash. In fact, statically linked executables ARE huge and he is wrong. He wants to criticise dynamic linking, but in fact only compares uclibc to glibc. Several people argue (with implicitly requiring ABI-stability) that dynamically linked executables benefit from security fixes in libraries they depend on. What some people argue is true. If there is a vulnerability in zlib (which actually happened a few years back), all that is needed is to rebuild zlib and be happy. A statically linked system would need to find every single binary that incorporates zlib and rebuild it. IMO either way this is a non-argument (in both directions), because any sane distribution should be able to pinpoint what needs to be rebuilt. In a dynamically linked situation, nothing (except the original library) needs to be rebuilt. That is easy to pinpoint. Now, if you only provide static libraries, your users will link self-compiled tools against those. This happens automatically without the user noticing. There is no tool in the world that can tell you which binaries have been linked against library libfoo.a. You cannot get away by saying that the distribution should be able to pinpoint it. There are no records of such dependencies in the binaries. If you write down which libraries have been used, you will forget one, because common build systems have no way of recording that. You have to write all of them down manually. This is true to some extend, but if there is a security flaw in a dynamically linked library, all programs are affected as well; whereas statically executables aren’t. This is the biggest pile of nonsense I ever read. If there is a flaw in a library, all programs that use it are affected - including statically linked executables that were built using that library. That wording seems lost in translation (it was written by Anselm, who is not a native English speaker). I suspect it is supposed to read statically linked executables aren't affected by vulnerabilities in the dynamic libraries installed on your system. I'll rewrite that. Statically linked binaries are affected by the vulnerabilities in the static libraries that were installed on your system _at build time_. That is what needs to be said here and it is the single strongest argument against static linking. The language barrier is no excuse for not saying that. It is even worse: There is no easy way to determine which version of the library a specific binary was built against. This is a security nightmare. Well, there isn't any more of a way to do that with dynamic linking, There is no need to do it with dynamic linking: Any bugs (relevant to security or not) are not in the binary, but only in the shared library. Replacing the shared library with a fixed version solves the bug. signature.asc Description: OpenPGP digital signature
Re: [arch-general] 64 bit kernel with 32 bit userspace
Am 21.08.2013 06:22, schrieb Magnus Therning: On Tue, Aug 20, 2013 at 03:56:50PM +0100, Laszlo Papp wrote: Hi, based on the following forum entry, I would like to open this topic up for a wide discussion. https://bbs.archlinux.org/viewtopic.php?pid=1314594 Slightly unrelated, but is that link supposed to work? For me it's incorrect or outdated. The topic has been moved to the topics going nowhere subforum, which is only accessible if you log in. signature.asc Description: OpenPGP digital signature
Re: [arch-general] mkarchiso operates poorly with new glibc-2.18 built without pt_chown
Am 15.08.2013 18:00, schrieb Vadim Ushakov:
mkarchiso init executes command mount -t devpts devpts
${work_dir}/root-image/dev/pts
Executing that command seems to drop mount options of /dev/pts, now we
have both devpts mount points have the same options:
vadim@aquila:~$ mount -t devpts
First, this seems like a kernel bug. The old mount point should not be
changed in this case - if they necessarily must have the same option,
the new mount point should get the options of the existing one.
One should either use a --bind mount call or use the 'newinstance'
option. The latter brings a few small issues, but those can be worked
around.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Upstream urls and package descriptions
Am 01.08.2013 18:02, schrieb Karol Blazewicz: Upstream urls: I found that dozens of packages in the repos have an upstream url that prints 'Page Not Found' in one way or another. Should I open bug reports for these packages or does nobody care about it? I could also check if the source is still available. If opening bug reports is OK, should I limit creating the reports to e.g. 10 a day? If I find a url that works, I will include it as a suggestion for the maintainer. Creating bug reports is the way to go here. It actually doesn't matter how many you create, the maintainers will fix them when they fix them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] linux-3.10.2-1 in [testing], still broken community modules
Am 22.07.2013 16:47, schrieb Tobias Powalowski: Hi, I built the kernel, now there are issues with following - community binary modules: cdfs ndiswrapper open-vm-tools-modules Please find patches and fix those, 3.10 will move to [core] when signoff procedure is done. This warning has been posted weeks ago already and nothing happened about it. There was not even a message from the maintainers about the status ([1]). Since 3.9 is EOL now, we will move 3.10 whether those modules are fixed or not and as a result, drop the aforementioned packages. [1] By maintainers I mean TUs who cannot even afford to react to an email that affects their package. Maybe we should start insulting people like Linus does. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Apache 2.4 revisited
Am 11.07.2013 15:45, schrieb Armin K.: As a side note, apache24 uses event_mpm by default, but you might need to change to prefork one to use PHP module. Also, with apache 2.4 you can use php-fpm via mod_proxy as described at [3] As for the perl module, I had to use svn checkout of the httpd24 branch. Patch was getting way to big to ship in package. Regards [1] https://mailman.archlinux.org/pipermail/arch-general/2012-October/031777.html [2] http://blackprince.net63.net/apache24/ [3] https://wiki.apache.org/httpd/PHP-FPM Using php-fpm with mod_proxy_fastcgi sounds interesting. Personally, I don't care whether mod_php breaks or not, since using fpm even on small installations seems like the superior method. Sigh, no one seems to care. Well, nothing strange. Patches will remain on the site in case someone needs them. You might try to write an email to jgc directly, since I have no idea if he reads arch-general at all. He stated in the past that nothing works with Apache 2.4, I have no idea if your post will convince him otherwise. signature.asc Description: OpenPGP digital signature
Re: [arch-general] syslinux 6.01-1 issues
Am 05.07.2013 20:46, schrieb Jonathan Hudson: And if you have a custom syslinux.cfg, you need to restore than from syslinux.cfg.pacsave. So many ways to break your boot That has already been fixed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] syslinux 6.01-1 issues
Am 05.07.2013 20:24, schrieb Karol Blazewicz: I'm using syslinux for my bootloader. I'm using BIOS, not UEFI, on a 32-bit system. After updating syslinux 5.10-3 - 6.01-1 the modules' symlinks in /boot/syslinux didn't get updated and still point to /usr/lib/syslinux/ instead of to /usr/lib/syslinux/bios e.g. menu.c32 - /usr/lib/syslinux/menu.c32 which prevents the syslinux menu from appearing on boot (modules not found). Running '# /usr/bin/syslinux-install_update -i -a -m' doesn't help. Should I remove all the symlinks from /boot/syslinux and only copy the needed files back? I didn't install syslinux manually so i don't know why should I have to do this. Did I miss / misunderstand something? The install script needs an update. Just remove the .c32 and ln -s /usr/lib/syslinux/bios/*.c32 . signature.asc Description: OpenPGP digital signature
Re: [arch-general] syslinux 6.01-1 issues
Am 05.07.2013 21:22, schrieb Karol Blazewicz: Should I open a bug report? If you don't plan on fixing it immediately, please post a message on arch-dev-public, because not everyone is reading arch-general even though this seems to be only an annoyance, not a system-breaking bug. This should be fixed before it moves to core. It is already being worked on. signature.asc Description: OpenPGP digital signature
Re: [arch-general] interference of the recent /usr symlinking with the mkinitcpio 'usr' hook?
Am 25.06.2013 12:34, schrieb Karol Blazewicz: In the meantime, I've solved the problem: It's my separate /etc partition (or subvolume, to be more correct). Separating the / and the /etc volume is inherently impossible and will never be supported. Don't do it. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Apache, systemd-tmpfiles
Am 24.06.2013 23:10, schrieb João Pires: So after a while I find the systemd-tmpfiles and the thing is the apache.conf in the /usr/lib/tmpfiles.d only creates the /run/httpd folder, after I add a new line to also create the /var/log/httpd the service start running again. You should add your own modifications in /etc/tmpfiles.d - the ones in /usr/lib/tmpfiles.d/ are overwritten on updates. So my question is, can this be considered a bug? should I create a bug report? This is perfectly normal behaviour - your setup is rather unusual, so extra configuration files in /etc are normal. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Super weird dd problem.
Am 10.06.2013 05:18, schrieb Anatol Pomozov: sync is not a workaround, it is a right solution. You are wrong. Under the hood copying in linux works following way. Every time you read something from disk the file information will stay cached in memory region called buffer cache. That is true - on a mounted file system. Writing directly to a block device (like /dev/sdb) does not use the buffer cache in any way. 3) Call dd operation with conv=fsync flag, this tells that dd should not return until all data is written to the device. Again, fsync only affects files on a mounted file system, not raw block devices. signature.asc Description: OpenPGP digital signature
Re: [arch-general] openssl cant find root certificate
Am 31.05.2013 16:39, schrieb G. Schlisio: hi list, if i run wpa_supplicant on a eap-ttls network, it fails to set up tls properly: OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:02001002:system library:fopen:No such file or directory where does openssl search these ca-certs, where do i get them from (obviously not from the ca-certificates package, this is installed and contains .crt instead of .pem). isnt this supposed to work without manual intervention? any help appreciated. thanks georg Did you add ca_path=/etc/ssl/certs and ca_path2=/etc/ssl/certs to the options? signature.asc Description: OpenPGP digital signature
