[arch-dev-public] Fwd: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)
Hi guys, It was recently brought to my attention (see below) that we still ship net-tools in Arch. Should we perhaps start working on dropping that? I regularly run into users who use it without knowing that it is dead and broken. Moving it to the AUR would hopefully send the right message... I know that this will probably upset people's muscle-memory as most people probably have been using these tools for decades. I guess that's not an insurmountable problem for us though? Cheers, Tom -- Forwarded message -- From: Tom Gundersen t...@jklm.no Date: Thu, Apr 24, 2014 at 1:22 PM Subject: Re: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1) To: Mantas Mikulėnas graw...@gmail.com Cc: Oliver oli...@business-security.de, systemd-de...@lists.freedesktop.org systemd-de...@lists.freedesktop.org On Thu, Apr 24, 2014 at 12:30 PM, Mantas Mikulėnas graw...@gmail.com wrote: On Thu, Apr 24, 2014 at 1:06 PM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: Hi Oliver, You can specify Address= more than once as it is explained in http://www.freedesktop.org/software/systemd/man/systemd.network.html (Address=). And just for the record, use `ip addr` to make sure it works, because chances are that `ifconfig` won't show it. Since kernel 2.2, there can be several IP addresses on the same eth0 interface without having to use 'aliases', using `ip addr add` for example. networkd uses the new method as well. Unfortunately, `ifconfig` – even the last version that Arch has – only shows the first address to this day. PSA: never, ever, use ifconfig or friends. It has been dead upstream since sometime in the last millenium and is known to give you misleading or just wrong information. I thought we had dropped it from Arch to be honest... Maybe time to look at that... Cheers, Tom
Re: [arch-dev-public] providing grsecurity in [community]
On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay danielmi...@gmail.com wrote: Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it: https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852 Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this. I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide. If you were providing an alternative kernel temporarily as a testing-ground for things that would eventually get integrated in our main kernel, I'd be all for it. But the way I see it, everyone agrees that grsec is never going upstream and that this is not something we could ever integrate in the main kernel, so I think we should be very careful about splitting efforts which could have otherwise benefited the whole distro (such as support for AppArmor, TOMOYO, SELinux, whatever). In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel. Cheers, Tom
Re: [arch-dev-public] providing grsecurity in [community]
On Sat, Apr 19, 2014 at 11:47 PM, Daniel Micay danielmi...@gmail.com wrote: On 19/04/14 05:25 PM, Tom Gundersen wrote: On Sat, Apr 19, 2014 at 9:59 PM, Daniel Micay danielmi...@gmail.com wrote: Users have been asking for MAC to be provided in the repositories for a long time. At the moment, two bugs are open about it: https://bugs.archlinux.org/task/37578 https://bugs.archlinux.org/task/39852 Any of these reported bugs could simply be closed with the response that the grsecurity RBAC is provided in the repositories and there's no one interested in maintaining another. I think that's a response most people would be satisfied with, but users aren't going to be very happy with an a WONTFIX simply saying Arch has no official support for any of this. I would see this the other way around (which is one of the reasons I don't think adding forks of the kernel is such a great idea). It would be very nice if we could manage to support some more security features in the main kernel, but asking people to use an alternative kernel if they want security features seems wrong. Especially if it is used as an excuse not to get things that are already upstream working with the main kernel we provide. These features aren't in the regular kernel though. I was referring to SELinux and TOMOYO. Cheers, Tom
Re: [arch-dev-public] providing grsecurity in [community]
On Sat, Apr 19, 2014 at 11:58 PM, Daniel Micay danielmi...@gmail.com wrote: On 19/04/14 05:25 PM, Tom Gundersen wrote: In short, work on grsec if you want, but please let's not use that as an excuse to discourage people from working on similar features for the main kernel. For example, if someone opens a bug asking to enable CONFIG_AUDIT again, will it really be accepted? The workaround for containers landed in systemd. http://cgit.freedesktop.org/systemd/systemd/commit/?id=24fb111 That is clearly not an acceptable long-term solution. As far as I know audit is being fixed upstream to make this temporary work-around unnecessary. -t
Re: [arch-dev-public] providing grsecurity in [community]
On Wed, Apr 16, 2014 at 6:09 AM, Daniel Micay danielmi...@gmail.com wrote: There has been a recent surge of interest in securing Arch by paying closer attention to CVEs and addressing many security issues in our packages. I also started some initial work/documenting on securing the services shipped in various packages: https://wiki.archlinux.org/index.php/DeveloperWiki:Service_isolation I'm very happy that more people are now looking at security related things in Arch. Nice work! To go along with this, I'm interested in maintaining the grsecurity kernel and userspace tools in [community] to provide a hardened kernel and role-based access control system. This would be the first case of an alternative kernel in the repositories, so I'm open to discussion about whether it's appropriate to do this. There are also some issues relevant to other packages in the repositories. Hmm, grsec seems like a dead-end to me. It will never land upstream, and hence will never be in our standard kernel and our default packages will therefore never be integrated with it. So whatever work you do will have to live independently in perpetuity. At worst it would split our (very limited) development and QA resources. Would it not make more sense to focus on some other security features that are actually upstream and which can then at least potentially be merged into our default packages eventually? Maybe another option, if you really think grsec is the way to go, would be to simply create a new unofficial repository and put the packages there instead? Cheers, Tom The grsecurity project has been around since 2001 and has fundamentally different goals than the mainline Linux project. Much like OpenBSD, it makes changes with a measurable performance or compatibility impact that are unlikely to ever be included in the upstream kernel. Many of these changes involve hardening the kernel against userspace exploitation, which is not something tackled by any of the Linux Security Modules. Users, groups, ACLs, chroots and namespaces already provide a solid foundation for access control, so hardening the kernel itself is the single biggest security improvement involved. It has various odds and ends exposed via sysctl switches, and these tend to trickle upstream in one form or another (symlink/hardlink protection, dmesg restriction, /proc restrictions). It also includes the PaX project to provide a much stronger implementation of ASLR along with significant memory protections for userspace. These features do break many packages, and require setting flags on binaries when exceptions are necessary. I don't want to place a burden on other packagers, so I plan on leaving the parts requiring integration with other packages disabled at first. If there turns out to be more interest than just my own in maintaining this, flipping on the PaX protections by default and setting the required flags in various packages could be considered. I don't want to approach this by filing bugs, so there would need to be a developer interested in doing some work on packages in [core] and [extra] for these kinds of features to be enabled. SELinux requires many packages to be built with support for it, along with a significant number of patches. The policies are very complex and spread out through the entire file system. In my opinion, it's pretty much the antithesis of Arch's goals of simplicity and transparent configuration. AppArmor/TOMOYO are much simpler, with centralized policy files that are much easier to review or ship in packages. The grsecurity RBAC system is similar to these and has a nice automatic learning mode. However, it's quite a bit more powerful and grsecurity is useful even without providing RBAC policies since this is only one component. All in all, I think grsecurity would be a great way of improving the level of security we offer. It's also one of the least intrusive ways of doing it, since it can provide significant benefits without everyone buying into it and adding profiles to their packages. There will be no impact on the regular/default kernel, so it's far friendlier to users who don't care about this than SELinux/AppArmor/Audit.
Re: [arch-dev-public] Drop cronie and logrotate from base?
On Tue, Apr 1, 2014 at 9:30 PM, Andrea Scarpino and...@archlinux.org wrote: On Tue 01, April 20:48:16 Florian Pritz wrote: Moving to extra sounds good. +1 As Gaetan already agreed: +1 from me too. Move it to extra and make it a dep of everything that logs to /var/log by default, optdep for stuff that can be configured to log there. (both assume that the package actually has a logrotate config ofc) Is not needed for packages that log to /var/log (e.g. pacman), but for packages that install a logrotate.d script (42 at the moment). Yup, this seems good I'm not sure if this should be a dep or optdep though. If logging to /var/log is not configurable I'd make it a dep, if it is I'd make it an optdep... -t
Re: [arch-dev-public] [RFC] Add ARM to archlinux.org
On Fri, Mar 28, 2014 at 1:14 AM, Andrea Scarpino and...@archlinux.org wrote: On Mon 24, March 15:02:53 Gaetan Bisson wrote: Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone, I'm not sure if making it official would be a good thing (TM) in terms of encouraging users to downgrade packages rather than reporting bugs and upgrading cleanly when things break. I want to quote Gaetan and Dave here. I fear that making ARM official or semi-official we unconsciously boost single packages downgrade. I absolutely agree that we must make it abundantly clear that partial upgrades/downgrades are not supported. Never have been, and never will be. Apart from keeping this in mind when making any public statements on this subject (to avoid giving false expectations) I don't think it is a show-stopper though. If people do stupid things they get to keep the pieces when stuff breaks. We shouldn't let the fear of stupid people being stupid hinder our development. Another important point is that downgrading your whole system means you don't get any security upgrades or bug fixes, so in that sense it is not supported. In precisely the same way not upgrading your system is not supported. That said, I do think the ARM (or whatever its new name will be) is a really crucial service given our development model. We are on the bleeding edge, and our QA is more or less nonexistent. Surprisingly the quality of our packages is still very high (at least in my experience), but we do of course occasionally let the some buggy package slip through to core/extra/community. When this happens, the reasonable thing for a user to do is to file a bug and downgrade the package until the bug has been fixed. However, we don't support partial downgrades (at all, it would be a really, really stupid thing to do), so the only reasonable thing to do is to downgrade the whole system to a previously known good state (which is usually the state of the archives just before the offending package was updated). Doing this now is actually a real pain, as the user may not have all the necessary packages in their local cache, and even if they do, they can't easily know which packages to downgrade to what version. Another concern I have seen raised in the past is that if we make it simple to downgrade to temporarily avoid buggy packages, we will get fewer bug reports. I don't think that is a valid argument, rather we'd discourage users from upgrading frequently, or from using Arch at all. The argument is similar to a filesystem developer refusing to ship a fsck tool as it would allow people to fix their broken filesystems without filing bugs first... Having the ARM service (or something like that) with all the necessary caveats and warnings, makes it simple to force-downgrade to a given point in time, allowing users a reasonable fallback-mode in case some crucial package breaks on upgrade (and I mean crucial in the sense that it is something the user urgently needs, not in the sense that it is in [core], it could easily be a text editor, music player or web browser). So, in conclusion, I fully support adding such a service under the archlinux.org domain, and hosted on Arch infrastructure. This is under the assumption that care is taken when communicating precisely what this does and does not entail and someone is volunteering to do the actual work (and that whoever is actually affected by it on the infrastructure side do not object). If hosting it on our infrastructure is a problem, I'd suggest we pick up the bill for the current hosting costs instead, but still assign it an arch domainname and consider it officially part of our project. I have no comments regarding the details when it comes to pricing or other resources, except to say that we don't necessarily need a very long history, if space poses a problem, and that the kind of expenses indicated seems well within what we can afford (though we should of course always be respectful of our donors and try to keep expenses down when possible). Cheers, Tom
Re: [arch-dev-public] Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?
On Fri, Mar 28, 2014 at 3:01 AM, Gaetan Bisson bis...@archlinux.org wrote: [2014-03-27 21:01:17 -0400] Daniel Micay: setuid binary (crontab) so it opens up a vulnerability in the base install. Among others (although one requires cron to be enabled): * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0424 * https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-6097 There were bugs that have been fixed a while ago; what's your point? I support switching to systemd timers in order to streamline our base install, as well as regroup daemons and periodic commands configuration in just one place. But I do not believe that replacing a small setuid binary by a larger one addresses any potential security issue. I agree with Gaetan that I don't see the big security concern here. However, I'm always in favor of dropping stuff from base whenever the opportunity arises. Once other base packages no longer ship cron jobs, I suppose there is no longer a reason to keep cronie in base? What's your take on that Gaetan (not sure if your comment was against dropping it, or just against the security concern)? Cheers, Tom
Re: [arch-dev-public] 3.13 packages in testing
On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler tho...@archlinux.org wrote: One major change is coming (and Tom will be happy about it): Keyboard support is entirely modular, even for AT(PS/2) keyboards. Beware that in order to have keyboard input during early boot, you need the 'keyboard' hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A post-install message has been added. Awesome :-) \o/ -t
Re: [arch-dev-public] [RFC] preparing dbus for coexistence with kdbus
On Sun, Dec 1, 2013 at 7:05 PM, Tom Gundersen t...@jklm.no wrote: Work on kdbus is nearing completion (of a first version at least) and it will soon be submitted upstream. We will also soon have a 'bridge' in systemd between the old libdbus and kdbus. This bridge will conflict with the old dbus daemon, but libdbus will still be around for a long time. All of this stuff is very much still under development, and the details are not clear yet. However, to make it simpler for Arch users to help out with the testing and development of kdbus and its systemd counterpart, I'd like to propose the following: * split 'dbus' into 'dbus' and 'libdbus' * make dbus depend on libdbus * other packages will still depend on dbus, rather than libdbus directly. For the regular users, this should have no effect, but for people building and testing systemd/kdbus it means they can still stick with our stock libdbus rather than building their own. At some point in the future, I expect this will be beneficial to all, as we will likely drop the dbus and just keep libdbus around. Thoughts? Done. -t
[arch-dev-public] [HEADSUP] Arch boot splash
Hi guys, I thought I'd let you know that I just pushed a new version of gummiboot to [testing] which now has support for showing a splash-screen at boot [0]. I shipped it with the Arch Linux logo (/usr/lib/gummiboot/splash-arch.bmp), which can be copied to /boot/EFI/gummiboot/splash.bmp if you want to test it out (eventually this will 'just work', but we are not quite there yet). If your UEFI firmware is messed up, you may need to specify the background color in /boot/loader/loader.conf as, say, background #C0C0C0 (which is the Mac background color). I figure this might be interesting to use on our isos? Cheers, Tom [0]: https://plus.google.com/+TomGundersen/posts/FcVxvSqFc9M
Re: [arch-dev-public] [RFC] preparing dbus for coexistence with kdbus
On Mon, Dec 2, 2013 at 1:36 AM, Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar wrote: On 12/01/2013 03:05 PM, Tom Gundersen wrote: Hi guys, Work on kdbus is nearing completion (of a first version at least) and it will soon be submitted upstream. We will also soon have a 'bridge' in systemd between the old libdbus and kdbus. This bridge will conflict with the old dbus daemon, but libdbus will still be around for a long time. All of this stuff is very much still under development, and the details are not clear yet. However, to make it simpler for Arch users to help out with the testing and development of kdbus and its systemd counterpart, I'd like to propose the following: * split 'dbus' into 'dbus' and 'libdbus' * make dbus depend on libdbus * other packages will still depend on dbus, rather than libdbus directly. For the regular users, this should have no effect, but for people building and testing systemd/kdbus it means they can still stick with our stock libdbus rather than building their own. At some point in the future, I expect this will be beneficial to all, as we will likely drop the dbus and just keep libdbus around. Thoughts? Cheers, Tom Hola! Nice. I read that kdbus is only enabled in tarball build if you want, (so the support is optional at least for now) Maybe I am wrong, just guessing, but since our LTS kernel will not include kdbus, this implies that we have two systemd packages, one for standard kernel and other for lts kernel? It will still be a long time before this is enabled in a released version, and probably longer still before it will be required. I expect that when the time comes both our LTS and standard kernels will have kdbus support (it is just a module, backporting should be easy). Cheers, Tom
[arch-dev-public] [RFC] preparing dbus for coexistence with kdbus
Hi guys, Work on kdbus is nearing completion (of a first version at least) and it will soon be submitted upstream. We will also soon have a 'bridge' in systemd between the old libdbus and kdbus. This bridge will conflict with the old dbus daemon, but libdbus will still be around for a long time. All of this stuff is very much still under development, and the details are not clear yet. However, to make it simpler for Arch users to help out with the testing and development of kdbus and its systemd counterpart, I'd like to propose the following: * split 'dbus' into 'dbus' and 'libdbus' * make dbus depend on libdbus * other packages will still depend on dbus, rather than libdbus directly. For the regular users, this should have no effect, but for people building and testing systemd/kdbus it means they can still stick with our stock libdbus rather than building their own. At some point in the future, I expect this will be beneficial to all, as we will likely drop the dbus and just keep libdbus around. Thoughts? Cheers, Tom
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
On Wed, Nov 27, 2013 at 12:49 PM, Sébastien Luttringer se...@seblu.net wrote: On 27/11/2013 11:35, Thomas Bächler wrote: Am 27.11.2013 11:29, schrieb Allan McRae: Please don't do this... 11 line output in post_install. If you REALLY need this, use a single line pointing to the wiki page. Allan Usage instructions generally don't belong into install/upgrade messages. In the best case, there is no message at all. In this case, the install message contains basic systemctl commands and networking tips, none of this is specific to docker or urgent enough to be printed during pacman. This package has been pushed to svn too quicly. A discussion has been started in aur-general[1] and I stated that I'll managing addition. After a quick talk with Allan, I sent a mail to Daniel, to see if we can use the name docker for the new package instead of docker-io or lxc-docker. Let time to Daniel to answer. On the technical standpoint, this package needs refactoring, maybe build the binary from the source and not use the binary provided by dotcloud/docker inc. This needs more work to be done. Cheers, [1] https://mailman.archlinux.org/pipermail/aur-general/2013-November/026223.html This makes sense to me. It may be worth noting that the 'old' docker is installed by roughly 1% of our users, but according to their website is meant for use with GNOME2 and KDE3, which we don't even ship any more. I'd say dropping or renaming it makes the most sense and let this new package take the name 'docker', as that's what people will be looking for. Cheers, Tom
Re: [arch-dev-public] Fwd: [arch-commits] Commit in (9 files)
On Wed, Nov 27, 2013 at 2:43 PM, Alexander Rødseth rods...@gmail.com wrote:
Something like:
replaces=('docker=1.5')
in the docker-tray PKGBUILD?
Isn't that equally problematic, since that could cause problems if
docker (currently at version 0.7) reached version 1.5?
I guess this could be simply solved by introducing the new docker with
epoch=1...?
Re: [arch-dev-public] [arch-general] Dropping bluez4
On Wed, Nov 6, 2013 at 9:21 PM, Andreas Radke andy...@archlinux.org wrote: I've done some work and research on bluez lately. I can confirm my adapters to work with bluez 5.10 and gnome-bluetooth (connecting to headset + smartphone) that has already moved to extra. I couldn't make it work with kde+bluedevil that is in testing. Also it seems not possible to use plain bluetoothctl to pair (works sometimes)/connect(never working here) your device and use plain alsa/obex. This is an annoying situation for any other desktop apart from Gnome. Thanks for investigating this, I have not had as much time as I had hoped to sort out Bluez. For kde, I guess we'll just hold off on this, and wait for a new git snapshot/release that works. For the cli stuff, this is something that we should get fixed. Have you taken this upstream, that's probably the best approach. Blueman is broken and for many users not even starting. Yeah, that's expected (it requires bluez4 afaik). No idea about our networkmanager bluetooth support. Fedora 20 has switched over to only use bluez v5, OpenSuSE is also using it. We should search further how to solve kde and plain console situation. Is Bluez4 still required to use with obexd? If not we can drop it and focus on improving bluez5 support. Bluez5 comes with its own obex server, so the separate obex-server/obex-client can be dropped. Best would be to get bluez connecting to devices from console or/and to have a desktop independent frontend like this approach: http://mail.xfce.org/pipermail/xfce4-dev/2013-July/030408.html At least the console stuff should be fixed. Cheers, Tom
Re: [arch-dev-public] lirc kernel drivers
On Mon, Nov 4, 2013 at 5:11 PM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Am 14.10.2013 14:57, schrieb Tom Gundersen: Hi guys, As lirc package is currently an orphan, I thought I'd had a look at it to see if we can clean it up. Most of the lirc kernel drivers are now upstream, so we only ship three of them: *) lirc_atiusb: this overlaps with ati_remote [0] which is upstream. This is bad as it means users will essentially get a random driver loaded unless one of the two are blacklisted. Moreover, it is not possible to use both driver at the same time for different devices. It seems to me based on [1], that there is reason to doubt the validity of the modaliases that lirc_atiusb supports but ati_remote does not. I therefore suggest we drop lirc_atiusb and if there is fallout from this we try to fix that in ati_remote upstream (e.g. add missing modaliases). *) lirc_i2c: this was removed from staging in [2], as the functionality is replaced by ir-kbd-i2c (which appears to be written mostly by the same people). I suggest we remove this driver too as it appears to be redundant (though it has no autoloading support as far as I can tell, so probably less harmful). I got it confirmed from upstream that these are now redundant, so removed them from svn. *) lirc_wpc8769l: I suggest we keep this as the only remaining module for now. Based on comments in winbond-cir [3], that driver can probably be extended to support WEC102* (WPC8769L is WEC1020). I'll get in touch with the maintainers to check it out. Any comments? Tom [0] compare the aliases as shown by 'modinfo'. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5132088697fbfd1330facf723499091182f6ef91 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=41ca2b1ac269e2ed64e2562b91fa61cab0b19e7a [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/winbond-cir.c#n5 Do the changes you think are best, I never used lirc in any way. We now only have one lirc kernel module left, according to [0] it does not appear to be much used (i.e., not at all). If you want to avoid having to rebuild lirc for every kernel release you might want to drop the last module into the AUR, but I'll leave that decision up to you. Cheers, Tom [0]: https://www.archlinux.de/?page=ModuleStatistics On Mon, Nov 4, 2013 at 5:11 PM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Am 14.10.2013 14:57, schrieb Tom Gundersen: Hi guys, As lirc package is currently an orphan, I thought I'd had a look at it to see if we can clean it up. Most of the lirc kernel drivers are now upstream, so we only ship three of them: *) lirc_atiusb: this overlaps with ati_remote [0] which is upstream. This is bad as it means users will essentially get a random driver loaded unless one of the two are blacklisted. Moreover, it is not possible to use both driver at the same time for different devices. It seems to me based on [1], that there is reason to doubt the validity of the modaliases that lirc_atiusb supports but ati_remote does not. I therefore suggest we drop lirc_atiusb and if there is fallout from this we try to fix that in ati_remote upstream (e.g. add missing modaliases). *) lirc_i2c: this was removed from staging in [2], as the functionality is replaced by ir-kbd-i2c (which appears to be written mostly by the same people). I suggest we remove this driver too as it appears to be redundant (though it has no autoloading support as far as I can tell, so probably less harmful). *) lirc_wpc8769l: I suggest we keep this as the only remaining module for now. Based on comments in winbond-cir [3], that driver can probably be extended to support WEC102* (WPC8769L is WEC1020). I'll get in touch with the maintainers to check it out. Any comments? Tom [0] compare the aliases as shown by 'modinfo'. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5132088697fbfd1330facf723499091182f6ef91 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=41ca2b1ac269e2ed64e2562b91fa61cab0b19e7a [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/winbond-cir.c#n5 Do the changes you think are best, I never used lirc in any way. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org
Re: [arch-dev-public] Dropping sysvinit-tools
On Sat, Oct 26, 2013 at 6:29 PM, Dave Reisner d...@falconindy.com wrote: The next release of procps-ng will contain pidof and clash with sysvinit-tools. The obvious decision is to use the maintained source of pidof. At this point, we'll be left with 3 binaries in sysvinit-tools, all which I propose are all obsolete: fstab-decode, killall5, and bootlogd. I'm open to arguments against this, but I suggest we drop sysvinit-tools after pidof is part of a release from procps-ng. Yes, please do. Cheers, Tom
[arch-dev-public] lirc kernel drivers
Hi guys, As lirc package is currently an orphan, I thought I'd had a look at it to see if we can clean it up. Most of the lirc kernel drivers are now upstream, so we only ship three of them: *) lirc_atiusb: this overlaps with ati_remote [0] which is upstream. This is bad as it means users will essentially get a random driver loaded unless one of the two are blacklisted. Moreover, it is not possible to use both driver at the same time for different devices. It seems to me based on [1], that there is reason to doubt the validity of the modaliases that lirc_atiusb supports but ati_remote does not. I therefore suggest we drop lirc_atiusb and if there is fallout from this we try to fix that in ati_remote upstream (e.g. add missing modaliases). *) lirc_i2c: this was removed from staging in [2], as the functionality is replaced by ir-kbd-i2c (which appears to be written mostly by the same people). I suggest we remove this driver too as it appears to be redundant (though it has no autoloading support as far as I can tell, so probably less harmful). *) lirc_wpc8769l: I suggest we keep this as the only remaining module for now. Based on comments in winbond-cir [3], that driver can probably be extended to support WEC102* (WPC8769L is WEC1020). I'll get in touch with the maintainers to check it out. Any comments? Tom [0] compare the aliases as shown by 'modinfo'. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5132088697fbfd1330facf723499091182f6ef91 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=41ca2b1ac269e2ed64e2562b91fa61cab0b19e7a [3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/winbond-cir.c#n5
Re: [arch-dev-public] Git
On Sun, Sep 29, 2013 at 9:00 PM, Alexander Rødseth rods...@gmail.com wrote: As I gather, we all like git better than svn, for a long list of reasons. Are there any objections to switching over from svn to git for repositories for the official packages? I'm strongly in favor of git, and would be happy to work on the transition if we decide to make the switch. Yes, this can not be done in a heartbeat. The tools and documentation needs to be updated and the workflow needs to be tested, but are there objections to starting the transition process? If we are going to do this change, let's spend some time on discussing how we want the new layout to be like. I think we can simplify stuff a lot compared to current svn. -t
Re: [arch-dev-public] Git
On Sun, Sep 29, 2013 at 9:48 PM, Connor Behan connor.be...@gmail.com wrote: On 29/09/13 12:25 PM, Alexander R?dseth wrote: Hi, As I gather, we all like git better than svn, for a long list of reasons. Are there any objections to switching over from svn to git for repositories for the official packages? One reason to prefer svn is that you can do a non-recursive checkout and only have working copies of the packages you maintain. AFAIK, git does not (want to) support this. Yes, this can not be done in a heartbeat. The tools and documentation needs to be updated and the workflow needs to be tested, but are there objections to starting the transition process? If we were to use git, we should have one git repository per package, and also provide one repository which includes all the packages as submodules. This will allow both partial and full checkouts, just like with svn. Cheers, Tom
Re: [arch-dev-public] replacing efibootmgr with efibootmgr from peter jones with libefivar support?
On Mon, Sep 9, 2013 at 3:16 PM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: while improving archboot's uefi capabilities, Keshav which wrote most of the UEFI documentation on wiki comes up with this wish to switch to Peter Jones efibootmgr. For explanation for sysfs-efivar vs.efivarfs, efivarfs is the future in the kernel. https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Inconsistency_between_efivarfs_and_sysfs-efivars His efibootmgr uses the efivar library.This efibootmgr supports efivarfs and with this probably there is no need to use sysfs-efivars interface at all. This efibootmgr also contains many fixes and supports native efistub entries without truncation of loader path or the extra arguments passed via -u or -@ options. The actual upstream author is very slow in responding to queries, therefore I suggest switching to Peter Jones's code instead. For those who do not know Peter Jones, he is Fedora's efibootmgr (and few other boot loader related pkgs) maintainer. Are there any objections in switching to this efibootmgr version? If we decide to switch to this version efivar package need to move to [core] with it and we can disable the efivar module in kernels. This makes sense to me. If understand correctly using both efivars and efivarfs during the same boot is very fragile (at least I have managed to make the kernel panic doing this). So if we can make it no longer necessary (or even better: make it impossible) to use both interfaces, that would be great. Cheers, Tom
[arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools
Hi guys,
As you can see below, util-linux-24 will contain most of the tools
from sysvinit-tools. I therefore intend to propose that we drop
sysvinit-tools once util-linux-24 is out.
If anyone have any objections or concerns, this would be the perfect
time to speak up, so we can sort out any problems before the release.
Cheers,
Tom
-- Forwarded message --
From: Karel Zak k...@redhat.com
Date: Tue, Aug 13, 2013 at 3:51 PM
Subject: sysvinit last, lastb, wall, mesg
To: util-li...@vger.kernel.org
Cc: Ondrej Oprala oopr...@redhat.com
We have started sysvinit utils consolidation long time ago
(mountpoint, utmpdump, etc.). I'd like to finish this task in v2.24.
The goal is to make sysvinit[-tools] package unnecessary and maintain
generic init independent commands in utils-linux (and procps).
v2.24 changes:
* I have merged last/lastb from sysvinit
The sysvinit implementation is better than the original util-linxu
code. The problem is that command line options are incompatible, so
the old util-linxu version is temporary available by
--enable-deprecated-last.
* wall(1) from util-linux has been improved to accept a message on
command line to be compatible with sysvinit implementation.
* mesg(1) seems already compatible, so no change.
All the commands are enabled by default now. Use --disable-{last,wall,mesg}
if you don't like this decision.
Thanks to Ondrej (in CC) for his help with this boring work.
Karel
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line unsubscribe util-linux in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[arch-dev-public] [AWAY] until the end of August
Hi guys, Just letting you know that I'll be on holiday (with email, but no signing keys) until the end of this month. Feel free to do whatever is necessary to my packages. Cheers, Tom
Re: [arch-dev-public] [HEADSUP] util-linux deprecating sysvinit-tools
On Tue, Aug 13, 2013 at 6:30 PM, Thomas Bächler tho...@archlinux.org wrote: Am 13.08.2013 16:06, schrieb Thomas Bächler: Am 13.08.2013 15:59, schrieb Tom Gundersen: Hi guys, As you can see below, util-linux-24 will contain most of the tools from sysvinit-tools. I therefore intend to propose that we drop sysvinit-tools once util-linux-24 is out. If anyone have any objections or concerns, this would be the perfect time to speak up, so we can sort out any problems before the release. I think ppp uses 'pidof' in some scripts. pidof is similar to pgrep, but not quite the same. The other remaining tools (bootlogd, fstab-decode, killall5) seem to serve no purpose anymore. Relevant thread here: http://www.freelists.org/post/procps/pidof-in-procpsng Good to know. So it looks like procps-ng will adopt pidof, so we should wait for that before dropping sysvinit-tools completely. Cheers, Tom
Re: [arch-dev-public] The next LTS
On 6 Aug 2013 01:30, Thomas Bächler tho...@archlinux.org wrote: We might as well keep 3.10 for another 2 years. For what it is worth, I would really prefer if we only keep each LTS until the next one is out (i.e., one year). The reason being that running new user space on an old kernel is explicitly not supported and not tested (the converse is of course ok), so the longer our lts kernel lags user space the bigger the risk of inadvertently introduced regressions. Cheers, Tom
Re: [arch-dev-public] Syslinux 6.0 released with efi support
On Fri, Jun 21, 2013 at 12:08 PM, Pierre Schmitz pie...@archlinux.de wrote: Am 21.06.2013 11:52, schrieb Tobias Powalowski: Hi, my plan for this release will be to replace the syslinux package with syslinux-bios and package the efi part as syslinux-efi package. This will be like the grub packages. Cant we just use one package? Unless this is required by upstream (e.g. conflicting file names) I would not split this. The grub packages are a mess. +1 on that. I read the message from Keshav and also discussed a bit with him online. This is my take on the situation: There is no need to split up the syslinux package at all (nor grub for that matter) except if we want to support running 32-bit kernel together with 64-bit efi. We don't want to do that as, to the best of my knowledge, on any machine with 64-bit efi one can also use a 64-bit kernel, so I don't think this case is worth taking into consideration. Moreover, I think that using a different arch in the firmware and the kernel is not a good idea in general (even with 32-bit efi and 64-bit kernel, which in principle could boot). Unless the situation has changed, the kernel will apparently not be able to speak with the firmware after boot [0]. I dropped cross-arch support from gummiboot some time ago, and never heard a complaint. I suggest we do that everywhere, unless anyone can show a use-case where it is needed, and actually works as expected. Cheers, Tom [0]: https://bugzilla.redhat.com/show_bug.cgi?id=746421#c1 (thanks to Keshav for the reference).
Re: [arch-dev-public] [RFC] move libusb-compat from [core] to [extra]
On Sun, Jun 16, 2013 at 12:35 PM, Tom Gundersen t...@jklm.no wrote:
I'd like to move libusb-compat out of [core], any objections?
No other packages in [core] depends on it, but gnupg {opt,make}depends on it.
Done.
-t
[arch-dev-public] [RFC] moving gummiboot to core
Hi, Tobias and I would like to move gummiboot from [extra] to [core]. For those who don't know, it is a very minimal boot loader for uefi systems [0], currently used on our iso. Any objections? Tom [0]: http://freedesktop.org/wiki/Software/gummiboot/
[arch-dev-public] [RFC] move libusb-compat from [core] to [extra]
Hi guys,
I'd like to move libusb-compat out of [core], any objections?
No other packages in [core] depends on it, but gnupg {opt,make}depends on it.
Cheers,
Tom
Re: [arch-dev-public] [RFC] Bluez 5
On Mon, May 13, 2013 at 6:02 PM, Tom Gundersen t...@jklm.no wrote: I would like to push Bluez 5 to the repos, and rename Bluez 4 to 'bluez4'. Some things still require Bluez 4, and the two can not be installed together, so this is how I propose to do it. We will have the following packages: bluez4: the bluetooth daemon, providing the old dbus interface (a pared down version of our current 'bluez' package) bluez: the bluetooth daemon, providing the new dbus interface (not backwards compatible) bluez-libs: the libraries split off from the bluez package (backwards compatible) bluez-utils: the (development and testing) tools split off from the bluez package (backwards compatible) All packages currently depending on 'bluez' will have to be rebuilt to depend on 'bluez-libs' (most packages), 'bluez4' (at least libbluedevil) or 'bluez' (if anything has support for this). Packages that simply makedepend do not need to be rebuilt, just change the dependency in SVN (there is no soname bump). bluez-5 and bluez4 have now moved to extra. -t
Re: [arch-dev-public] [RFC] Bluez 5
On Thu, Jun 6, 2013 at 9:15 AM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Am 06.06.2013 07:49, schrieb Jan Alexander Steffens: On Thu, Jun 6, 2013 at 7:38 AM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Please don't move qemu with bluez move. qemu 1.5.0 is a bit to buggy to leave testing repository. If you move i'll bump extra 1.4.x with correct depends. I guess you could put qemu 1.4.1-4 with correct depends into [staging] right now, so that it's ready to be moved right to [extra] once bluez 5 leaves [testing]. Done added to staging repository. Thanks for the heads up! Cheers, Tom
Re: [arch-dev-public] New draft - Was: /usr move - update instructions
On Mon, Jun 3, 2013 at 5:05 AM, Allan McRae al...@archlinux.org wrote: And the news draft: Looks good to me. Time to make the move? -t
Re: [arch-dev-public] New draft - Was: /usr move - update instructions
On Mon, Jun 3, 2013 at 10:57 AM, Pierre Schmitz pie...@archlinux.de wrote: Am 03.06.2013 09:41, schrieb Tom Gundersen: On Mon, Jun 3, 2013 at 5:05 AM, Allan McRae al...@archlinux.org wrote: And the news draft: Looks good to me. Time to make the move? Fine with me. Maybe we could also explain more about the reasons or just link to you mail here: https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html We could add a link if you want (so as not to make the news item too long). -t
[arch-dev-public] Junior Devs
Hi guys, This was brought up a few times, so I'd like some clarification. What restrictions (apart from the possibility of getting the boot, and no read-access to arch-dev) do we put on Junior devs? It used to be that they could not push packages, but that is no longer a technical limitation. Should we still enforce it? Is there a restriction with respect to [core]? My preference would be to not have any limitation, but that they should be instructed to bring things up on ML / IRC when doing stuff for the first time to avoid problems. Cheers, Tom
Re: [arch-dev-public] Junior Devs
On Mon, Jun 3, 2013 at 4:48 PM, Thomas Bächler tho...@archlinux.org wrote: Am 03.06.2013 16:37, schrieb Tom Gundersen: Hi guys, This was brought up a few times, so I'd like some clarification. What restrictions (apart from the possibility of getting the boot, and no read-access to arch-dev) do we put on Junior devs? It used to be that they could not push packages, but that is no longer a technical limitation. Should we still enforce it? Is there a restriction with respect to [core]? On the new server, repo access and ftp access are using the same group. There is no special group for [core] access either. Makes it simple then. So the only question remains, do we want to tell people don't do that, or not? -t
Re: [arch-dev-public] [RFC] Bluez 5
On Mon, May 13, 2013 at 6:02 PM, Tom Gundersen t...@jklm.no wrote: I would like to push Bluez 5 to the repos, and rename Bluez 4 to 'bluez4'. Some things still require Bluez 4, and the two can not be installed together, so this is how I propose to do it. We will have the following packages: bluez4: the bluetooth daemon, providing the old dbus interface (a pared down version of our current 'bluez' package) bluez: the bluetooth daemon, providing the new dbus interface (not backwards compatible) bluez-libs: the libraries split off from the bluez package (backwards compatible) bluez-utils: the (development and testing) tools split off from the bluez package (backwards compatible) All packages currently depending on 'bluez' will have to be rebuilt to depend on 'bluez-libs' (most packages), 'bluez4' (at least libbluedevil) or 'bluez' (if anything has support for this). Packages that simply makedepend do not need to be rebuilt, just change the dependency in SVN (there is no soname bump). I put bluez/bluez4 in [staging] so we can move ahead with this. -t
Re: [arch-dev-public] Finishing the /usr move
On Fri, May 31, 2013 at 5:50 AM, Allan McRae al...@archlinux.org wrote: Doing a pacman -Syu gave a conflict as expected. Did not test that pacman -Syu --force failed, because it was on my only working system at the moment. The followed the instructions above. Rebooted at the end for good measure. DONE! No issues. I did the same yesterday, no issues for me either. Also checked that in case a package with files in /sbin (or so) is left we get the expected conflict. -t
Re: [arch-dev-public] Finishing the /usr move
On Fri, May 31, 2013 at 1:35 PM, Sébastien Luttringer se...@seblu.net wrote: Why not symlink /usr/local/sbin to /usr/local/bin in filesystems? I think we should do this, but not everyone agrees. As it is independent of the current move, let's discuss it once that has finished. -t
[arch-dev-public] [RFC] new default PATH
Hi guys, When updating our default PATH in /etc/profile due to the usrmerge I noticed it is not consistent with the system-wide PATH set by PID1. systemd sets: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin which for us is equivalent to /usr/local/sbin:/usr/local/bin:/usr/bin but profile used to set: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin which for us is equivalent to /usr/local/bin:/usr/bin:/usr/local/sbin For consistency I changed (in testing) the path set in /etc/profile to /usr/local/sbin:/usr/local/bin:/usr/bin Any objections? Tom
Re: [arch-dev-public] [RFC] new default PATH
On Sat, Jun 1, 2013 at 1:09 AM, Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar wrote: On 05/31/2013 04:04 PM, Tom Gundersen wrote: Hi guys, When updating our default PATH in /etc/profile due to the usrmerge I noticed it is not consistent with the system-wide PATH set by PID1. systemd sets: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin which for us is equivalent to /usr/local/sbin:/usr/local/bin:/usr/bin but profile used to set: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin which for us is equivalent to /usr/local/bin:/usr/bin:/usr/local/sbin For consistency I changed (in testing) the path set in /etc/profile to /usr/local/sbin:/usr/local/bin:/usr/bin Any objections? Tom will be made the symlink for sbin - bin for /usr/local ? I think we should eventually, but we are not doing it at the moment (and a few people object to it). My plan was to write an RFC for that once the current transition has finished. -t
Re: [arch-dev-public] [RFC] dropping LILO?
On Tue, May 21, 2013 at 8:41 AM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: Am 16.05.2013 01:20, schrieb Tom Gundersen: Hi guys, I was just going through some of the orphans in the usrmove TODO list and noticed that lilo is one of them. If no one wants to adopt it, perhaps we should drop it to the AUR. Or are there any reasons to keep it around? Cheers, Tom I don't use lilo anymore and also I could kill a install routine in archboot if it's not there anymore. +1 from me for dropping. Done. -t
Re: [arch-dev-public] Finishing the /usr move
On Thu, May 30, 2013 at 5:35 AM, Allan McRae al...@archlinux.org wrote: On 30/05/13 06:23, Eric Bélanger wrote: On Tue, May 28, 2013 at 9:56 PM, Allan McRae al...@archlinux.org wrote: I'm bored of waiting... so lets do this! What a plans with regard to [staging] in the near future? When it is free, I will kill the current TODO list and create a new one. I just moved the openobex rebuild to the testing repo. The staging repos are currently empty. Good. Rebuild has started. I may have possible added to many packages to the TODO list initially, so people will have received emails about packages that are already done. Thanks Allan. The rebuild is now well under way and, even thought not all of [core] is done yet, it should already be possible to upgrade a very minimal system to [staging] (in case anyone wants to test that things are working as they should). -t
Re: [arch-dev-public] Adding !staticlibs to our default makepkg.conf
On Wed, May 29, 2013 at 3:31 AM, Allan McRae al...@archlinux.org wrote: We discussed removing static libraries for most packages back in March [1]. Now makepkg for pacman-4.1 has an option staticlibs that automatically removes them. Should I make that the default in our makepkg.conf? Sounds like a reasonable default. +1 from me. -t
Re: [arch-dev-public] Finishing the /usr move
On Wed, May 29, 2013 at 3:56 AM, Allan McRae al...@archlinux.org wrote: I'm bored of waiting... so lets do this! Please do. I suppose people can still skip staging for packages where that makes sense to minimize the congestion? What a plans with regard to [staging] in the near future? If you don't do this soon-ish I was going to do some bluez stuff, but I'm happy to wait if this moves forward. -t
Re: [arch-dev-public] Removing glib 1, gtk 1 and qt3
On Wed, May 22, 2013 at 10:24 PM, Giovanni Scafora giova...@archlinux.org wrote: Il 21/05/2013 13:12, Jan Alexander Steffens ha scritto: Greetings everypony, Can we throw out glib 1, gtk 1 and qt3? These are seriously legacy libraries. Check pactree -rs glib and pactree -rs qt3 for dependent packages. Cheers, Jan I give a big -1 to removing glib 1, gtk 1 and qt3 from the repo. Why? -t
Re: [arch-dev-public] Removing glib 1, gtk 1 and qt3
On Wed, May 22, 2013 at 10:33 PM, Andrea Scarpino and...@archlinux.org wrote: On Wednesday 22 May 2013 10:20:42 Eric Bélanger wrote: Beside the fact that they are old, is there any reason to remove them from the repo? I maintain these threee packages and they are working well (no bug assigned). I don't see why they should be removed especially since many apps still depends on them. I'd like to get rid of those libraries too, but Eric maintain them and this is enough. I agree. If ever they start causing problems we could revisit the issue. -t
Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)
On Wed, May 15, 2013 at 1:02 PM, Bartłomiej Piotrowski b...@bpiotrowski.pl wrote: SMTP forwarders aren't as crucial as bash is, therefore I don't see any reason to revert changes or delay moving binaries to /usr/bin. Just message maintainer that his package is broken due to recent changes. I see that this is a borderline case, but I agree with Allan and Pierre, no need to break stuff unnecessarily. Please revert (or add a symlink). Cheers, Tom
[arch-dev-public] [RFC] dropping LILO?
Hi guys, I was just going through some of the orphans in the usrmove TODO list and noticed that lilo is one of them. If no one wants to adopt it, perhaps we should drop it to the AUR. Or are there any reasons to keep it around? Cheers, Tom
Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)
On Tue, May 14, 2013 at 10:49 PM, Dave Reisner d...@falconindy.com wrote: On Tue, May 14, 2013 at 10:37:43PM +0200, Sébastien Luttringer wrote: On Tue, May 14, 2013 at 10:22 PM, Bartłomiej Piotrowski bpiotrow...@nymeria.archlinux.org wrote: Date: Tuesday, May 14, 2013 @ 22:22:08 Author: bpiotrowski Revision: 90846 upgpkg: fail2ban 0.8.8-3 - correct path to sendmail due to migration to /usr/bin I see you moved exim from /usr/sbin/sendmail to /usr/bin/sendmail. This path is hardcoded to /usr/sbin/sendmail in _many_ sotfwares and all others rely on it (ssmtp, postfix, opensmtpd, heilroom-mailx, etc). By example, # mail -s toto se...@seblu.net test . EOT /usr/sbin/sendmail: No such file or directory /root/dead.letter 9/210 . . . message not sent. I think we should do this correctly and rebuild /usr/sbin/sendmail in one shot, or include it in the global switch. It's only hardcoded as /usr/sbin/sendmail for mailx because that's what the PKGBUILD for heirloom-mailx sets it to. Other packages can be fixed as well. I'm not following. If this path is hardcoded in several packages (and presumably in lots of custom packages/scripts), isn't this precisely one of the cases where we should delay the move until we do the proper usrmove and create the compat symlinks? Cheers, Tom
[arch-dev-public] [RFC] Bluez 5
Hi guys, I would like to push Bluez 5 to the repos, and rename Bluez 4 to 'bluez4'. Some things still require Bluez 4, and the two can not be installed together, so this is how I propose to do it. We will have the following packages: bluez4: the bluetooth daemon, providing the old dbus interface (a pared down version of our current 'bluez' package) bluez: the bluetooth daemon, providing the new dbus interface (not backwards compatible) bluez-libs: the libraries split off from the bluez package (backwards compatible) bluez-utils: the (development and testing) tools split off from the bluez package (backwards compatible) All packages currently depending on 'bluez' will have to be rebuilt to depend on 'bluez-libs' (most packages), 'bluez4' (at least libbluedevil) or 'bluez' (if anything has support for this). Packages that simply makedepend do not need to be rebuilt, just change the dependency in SVN (there is no soname bump). Any objections? Cheers, Tom
Re: [arch-dev-public] Merging the bin directories
On Sun, May 12, 2013 at 7:56 AM, Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar wrote: Looks like we are going one step more compared to Fedora right? /bin /sbin /usr/sbin - /usr/bin (Arch Linux) /bin - /usr/bin AND /sbin - /usr/sbin (Fedora) Correct. For what it's worth, I asked the Fedora guys if there was a good reason they didn't go all the way, and there wasn't (they plan to do it in the future). Cheers, Tom
Re: [arch-dev-public] Merging the bin directories
On Sun, May 12, 2013 at 10:44 AM, Thomas Bächler tho...@archlinux.org wrote: Am 12.05.2013 07:22, schrieb Allan McRae: I have created a TODO list with all packages that have files in /bin, /sbin or /usr/sbin. As the list is fairly long, the first pass will be to adjust as many packages as possible to install their files in /usr/bin instead. Some packages clearly can not have that done and will have to wait until we are prepared to replace those directories with symlinks. List of showstoppers: - Shells (with hardcoded paths in users' passwd) - fsck helpers (all hardcoded to be in /sbin) All mount and fsck helpers should be ok to move to /usr/bin. At least from mount and fsck's point of view, did you have something else in mind?. -t
Re: [arch-dev-public] Merging the bin directories
On Sun, May 12, 2013 at 11:58 AM, Rémy Oudompheng remyoudomph...@gmail.com wrote: Is it safe to move a daemon to /usr/bin where any user can access its binary (e.g. my cups pkg)? Sure... They were not magically hidden when in /usr/sbin. It is even a pain that very useful binaries like ip, ifconfig, lsof are in /sbin or /usr/sbin which is often not in user's PATH. Yeah, split sbin was always a pain. Which (if I remember correctly) is why we have been putting it in the user's PATH for some time (in effect making the split meaningless). -t
Re: [arch-dev-public] [testing] libtirpc 0.2.3-1 breaks pam_unix
On Sun, May 5, 2013 at 7:32 AM, Evangelos Foutras evange...@foutrelis.com wrote: On 5 May 2013 04:31, Jan Alexander Steffens jan.steff...@gmail.com wrote: libtirpc 0.2.3-1 breaks pam_unix, making login and su(do) impossible: May 05 03:22:54 philomeena login[24274]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/security/pam_unix.so: undefined symbol: log_debug May 05 03:22:54 philomeena login[24274]: PAM adding faulty module: /usr/lib/security/pam_unix.so I was lucky that one of my terminals still had a valid sudo timestamp, or I would have needed a reboot into rescue mode. I think we might need to rebuild the packages linking to libtirpc (nfs-utils, pam, rpcbind). This appears to be the same issue as when it was bumped from 0.2.2rc1 to 0.2.2rc3: https://bugs.archlinux.org/task/32308 I'm rebuilding and pushing to testing. -t
Re: [arch-dev-public] [testing] libtirpc 0.2.3-1 breaks pam_unix
On Sun, May 5, 2013 at 9:00 PM, Tom Gundersen t...@jklm.no wrote: On Sun, May 5, 2013 at 7:32 AM, Evangelos Foutras evange...@foutrelis.com wrote: On 5 May 2013 04:31, Jan Alexander Steffens jan.steff...@gmail.com wrote: libtirpc 0.2.3-1 breaks pam_unix, making login and su(do) impossible: May 05 03:22:54 philomeena login[24274]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/security/pam_unix.so: undefined symbol: log_debug May 05 03:22:54 philomeena login[24274]: PAM adding faulty module: /usr/lib/security/pam_unix.so I was lucky that one of my terminals still had a valid sudo timestamp, or I would have needed a reboot into rescue mode. I think we might need to rebuild the packages linking to libtirpc (nfs-utils, pam, rpcbind). This appears to be the same issue as when it was bumped from 0.2.2rc1 to 0.2.2rc3: https://bugs.archlinux.org/task/32308 I'm rebuilding and pushing to testing. Done. @tpowa: I had to add 'sqlite' as a depends to nfs-utils to make it build. Could you take a look to see if that was the right thing to do? Cheers, Tom
Re: [arch-dev-public] [arch-general] [pacman-dev] debug package repositories
On 15 Apr 2013 15:50, Rashif Ray Rahman sc...@archlinux.org wrote: On 15 April 2013 17:52, Allan McRae al...@archlinux.org wrote: In fact, I will provide the needed patches for a separate [debug] and [community-debug] repo if that is what is decided to happen. I personally think that is the only way to go about it. I wouldn't want -debug packages to take up search output, but I'd want them to exist somewhere accessible. Couldn't pacman be fixed to only show debug packages in search results when you ask for it with a switch? Maybe something similar could be done for language packages? An immediate possibility is to simply duplicate buildscripts to the debug repos and push only debug packages there. Of course, that'd be a manual process, and stuff won't be in sync/integrated, but it does mean that it's not anything impossible given our current packaging infrastructure. -- GPG/PGP ID: C0711BF1
Re: [arch-dev-public] [arch-general] [pacman-dev] debug package repositories
On Mon, Apr 15, 2013 at 4:53 PM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: On 15 April 2013 10:52, Allan McRae al...@archlinux.org wrote: In fact, I will provide the needed patches for a separate [debug] and [community-debug] repo if that is what is decided to happen. You have my full support when it comes to having debug packages in a separate repository. On 15 April 2013 15:00, Tom Gundersen t...@jklm.no wrote: Couldn't pacman be fixed to only show debug packages in search results when you ask for it with a switch? Maybe something similar could be done for language packages? A simple alias/wrapper using grep on the pacman output would work too ;-) Yeah, so why make a separate repo? What's the problem with keeping debug packages in the normal repos? -t
[arch-dev-public] [RFC] default sysctl settings
Hi guys, As you may have noticed systemd ships a default sysctl config file as of v199 (/usr/lib/sysctl.d/50-default.conf). Rather than also ship an Arch-specific one (/etc/sysctl.conf), should we try to unify the two? I had a look a the differences: 1) kernel.sysrq: We set it to 'off', systemd enables the sync command (which should be safe). 2) net.ipv4.ip_forward We disable this, which is already the default in the kernel. 3) net.ipv4.tcp_syncookies We enable this. Are we sure this is the right thing to do by default? There appears to be lots of warnings about it. 4) net.ipv6.conf.all.forwarding We disable this. It appears to be disabled by default, or am I reading it wrong? In addition to these, systemd sets the following: kernel.core_uses_pid = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 Are we happy with that? Cheers, Tom
[arch-dev-public] Fwd: [ANNOUNCE] util-linux v2.23-rc1
For your informawion. Please note that the tunelp tool has been deprecated and is no longer included. If this is a problem, please speak up now. I built and uploaded the release candidate for people to test: https://dev.archlinux.org/~tomegun/. Cheers, Tom -- Forwarded message -- From: Karel Zak k...@redhat.com Date: Fri, Mar 22, 2013 at 1:56 PM Subject: [ANNOUNCE] util-linux v2.23-rc1 To: linux-ker...@vger.kernel.org, linux-fsde...@vger.kernel.org, util-li...@vger.kernel.org The util-linux release v2.23-rc1 is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.23 Feedback and bug reports, as always, are welcomed. Karel Util-linux 2.23 Release Notes = The cryptoloop support in the commands mount(8) and losetup(8) has been REMOVED. The encryption= mount option and -e,-E,--encryption losetup options are no more supported. The command arch(1) has been REMOVED from util-linux in favour of coreutils version. The command chkdupexe has been REMOVED from util-linux. Release highlights -- nsenter(1): - this NEW COMMAND provides command line interface to setns() Linux syscall and allows to run program with namespaces of other processes unshare(1): - supports new PID and USER namespaces fdisk(8): - provides experimental support for GUID Partition Table (GPT), the implementation is still not complete and some (unimportant) features are missing. - ~50% of fdisk code has been refactored, this task is going to be complete in the next release. The goal is to have libfdisk shared between all fdisks. partx(8): - supports new update command (implemented by BLKPG_RESIZE_PARTITION ioctl) mount(8): - supports new userspace mount option x-mount.mkdir[=mode] to create mountpoints on demand - the support for propagation flags has been improved, now the flags could be specified in /etc/fstab and used together with regular mount options. It's also possible to specify more propagation flags together. This EXPERIMENTAL feature is implemented by additional mount(2) syscalls, because Linux does not allow to use propagation flags with another options or more flags together. umount(8): - supports new command line option --recursive to recursively unmount all sub-mounts for the specified mountpoint - supports new command line option --all-targets to unmount all mountpoints in the current namespace for the specified filesystem - the options --recursive and --all-targets could be used together dmesg(1): - supports new command line options --color, --human and --nopager, the --human option enables relative times, colors and pager support. su(1): - supports new command line options --group and --supp-group to specify primary and supplementary groups chfn(1) and chsh(1): - the commands could be linked with libuser to support non-local accounts modification (e.g. LDAP, etc). kill(1): - the command has been improved to be compatible with procps version, the procps version is deprecated now, the util-linux version is enabled by default. blkdiscard(8): - this NEW COMMAND discard sectors on a device (for example on SSD disks) sulogin(8): - provides multi-console feature from SysVinit findmnt(8): - provides new columns FREQ, PASSNO, ID, OPT-FIELDS, PROPAGATION lslocks(8): - provides new column BLOCKER and detects blocked locks lsblk(8): - supports new command line option --scsi and new columns HCTL, TRANsport VENDOR and REVision swapon(8) and losetup(8): - the commands prints basic overview by default if no option specified column(1): - supports new command line option --output-separator to specify table output delimiter rename(1): - supports new command line option --symlink to rename symlink target hwclock(8): - supports new command line option --compare to periodically compare the Hardware Clock to the System Time (based on adjtimex -c) ipcs(1): - supports new command line options --bytes and --human wipefs(1): - supports new command line option --force to force erase on used devices Stable maintenance releases between v2.22 and v2.23 --- util-linux 2.22.1 [10-Oct-2012] * ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/v2.22.1-ReleaseNotes ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/v2.22.1-ChangeLog util-linux 2.22.2 [13-Dec-2012] * ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/v2.22.2-ReleaseNotes ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.22/v2.22.2-ChangeLog Changes between v2.22 and v2.23 --- For more details see ChangeLog files at: ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.23/
Re: [arch-dev-public] BIND10? No, thanks.
On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee dpmc...@gmail.com wrote: host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling? util-linux does not. coreutils and iputils provide 'host', but both are incompatible with the legacy one (and, iirc, each other). -t
Re: [arch-dev-public] BIND10? No, thanks.
On Wed, Mar 20, 2013 at 2:59 PM, Dave Reisner d...@falconindy.com wrote: glibc ships getent, which can be used to do DNS lookups (getent hosts www.google.com). That said, I don't expect people to know this offhand as an alternative to dig. I'm kind of wary of not shipping *basic* DNS tools which people expect to exist. drill is not a drop-in replacement for dig given that it ignores the +option flags. If there are tools that do the same job, albeit in a different way or with a different syntax, I don't see the big problem here... And no, I don't buy this I disagree with upstream so I'm not shipping it as an excuse to not only avoid BIND10, but drop BIND entirely. Would be simple enough to adopt the BIND package... -t
Re: [arch-dev-public] BIND10? No, thanks.
On Wed, Mar 20, 2013 at 3:03 PM, Thomas Bächler tho...@archlinux.org wrote: Am 20.03.2013 14:42, schrieb Tom Gundersen: On Wed, Mar 20, 2013 at 2:34 PM, Dan McGee dpmc...@gmail.com wrote: host, nslookup, traceroute6- the list of extremely basic sysadmin tools Arch doesn't ship in an easily installable fashion is starting to get rather long. Does util-linux or such provide implementations of the first two that until now we have been disabling? util-linux does not. coreutils and iputils provide 'host', but both are incompatible with the legacy one (and, iirc, each other). -t They are certainly better than using either 'drill' or 'getent hosts/ahosts', all of which either return too much (drill and getent ahosts) or too few (getent hosts) information. If we can live with the incompatibility, I'd be in favor of moving 'host' to coreutils, but we have tried that before and people were not happy... -t
[arch-dev-public] FYI: systemd 198
/Specifications/BootLoaderSpec * Boot time console output has been improved to provide animated boot time output for hanging jobs. * A new tool systemd-activate has been added which can be used to test socket activation with, directly from the command line. This should make it much easier to test and debug socket activation in daemons. * journalctl gained a new --reverse (or -r) option to show journal output in reverse order (i.e. newest line first). * journalctl gained a new --pager-end (or -e) option to jump to immediately jump to the end of the journal in the pager. This is only supported in conjunction with less. * journalctl gained a new --user-unit= option, that works similar to --unit= but filters for user units rather than system units. * A number of unit files to ease adoption of systemd in initrds has been added. This moves some minimal logic from the various initrd implementations into systemd proper. * The journal files are now owned by a new group systemd-journal, which exists specifically to allow access to the journal, and nothing else. Previously, we used the adm group for that, which however possibly covers more than just journal/log file access. This new group is now already used by systemd-journal-gatewayd to ensure this daemon gets access to the journal files and as little else as possible. Note that make install will also set FS ACLs up for /var/log/journal to give adm and wheel read access to it, in addition to systemd-journal which owns the journal files. We recommend that packaging scripts also add read access to adm + wheel to /var/log/journal, and all existing/future journal files. To normal users and administrators little changes, however packagers need to ensure to create the systemd-journal system group at package installation time. * The systemd-journal-gatewayd now runs as unprivileged user systemd-journal-gateway:systemd-journal-gateway. Packaging scripts need to create these system user/group at installation time. * timedated now exposes a new boolean property CanNTP that indicates whether a local NTP service is available or not. * systemd-detect-virt will now also detect xen PVs * The pstore file system is now mounted by default, if it is available. * In addition to the SELinux and IMA policies we will now also load SMACK policies at early boot. Contributions from: Adel Gadllah, Aleksander Morgado, Auke Kok, Ayan George, Bastien Nocera, Colin Walters, Daniel Buch, Daniel Wallace, Dave Reisner, David Herrmann, David Strauss, Eelco Dolstra, Enrico Scholz, Frederic Crozat, Harald Hoyer, Jan Janssen, Jonathan Callen, Kay Sievers, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marc-Antoine Perennou, Martin Pitt, Mauro Dreissig, Max F. Albrecht, Michael Biebl, Michael Olbrich, Michal Schmidt, Michal Sekletar, Michal Vyskocil, Michał Bartoszkiewicz, Mirco Tischler, Nathaniel Chen, Nestor Ovroy, Oleksii Shevchuk, Paul W. Frields, Piotr Drąg, Rob Clark, Ryan Lortie, Simon McVittie, Simon Peeters, Steven Hiscocks, Thomas Hindoe Paaboel Andersen, Tollef Fog Heen, Tom Gundersen, Umut Tezduyar, William Giokas, Zbigniew Jędrzejewski-Szmek, Zeeshan Ali (Khattak) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [arch-dev-public] [arch-releng] FYI: systemd 198
On Fri, Mar 8, 2013 at 10:06 AM, Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar wrote: On 03/07/2013 09:35 PM, Tom Gundersen wrote: Hi guys, A new systemd release is out (not yet packaged though), and there are several features which might be of interest to us. Cheers, Tom -- Forwarded message -- From: Lennart Poettering lenn...@poettering.net Date: Fri, Mar 8, 2013 at 8:12 AM Subject: [systemd-devel] [ANNOUNCE] systemd 198 To: systemd Mailing List systemd-de...@lists.freedesktop.org Hey! Finally, here's 198, with many big changes: http://www.freedesktop.org/software/systemd/systemd-198.tar.xz In detail: * A number of unit files to ease adoption of systemd in initrds has been added. This moves some minimal logic from the various initrd implementations into systemd proper. I am excited in particularity for this feature, and how can be used for archiso, when mkinitcpio supports this. This should basically just work now, but I'd like to do a bit more testing before shipping a systemd mkinitcpio hook. I guess in a future, something similar will be happen to replace shutdown initramfs script with systemd, right? I did the minimal work to allow /usr/lib/systemd/systemd-shutdown to be used instead of our current /shutdown script, so this should work with v198. However, I think we want to improve the systemd shutdown logic to make it a bit more elegant before using it by default: * It should be a bit more clever about the order in which it tries to unmount things. * It should avoid printing ugly warnings from shutdown in the real root when the problems will anyway be solved in the shutdown ramfs. * Lastly, we should probably optimize the whole process by giving up early in the real root and jump into the shutdown ramfs as soon as possible. Patches welcome :-) Cheers, Tom
Re: [arch-dev-public] gummiboot-efi still in testing
On Tue, Mar 5, 2013 at 8:40 PM, Tobias Powalowski tobias.powalow...@googlemail.com wrote: somehow gummiboot-efi is still in testing, while gummiboot package is also there. Tom can you look at that and remove it? I'll move gummiboot to [extra] and remove gummiboot-efi everywhere soon. -t
Re: [arch-dev-public] Please provide Info for my talk!
On Mon, Feb 25, 2013 at 12:17 AM, Allan McRae al...@archlinux.org wrote: @Tom: I will ping you with what I got... In fact, you can also have a copy of my talk! Thanks! Disappointingly, I only have responses from 4 devs, 2 TU and 2 users. :(
Re: [arch-dev-public] Please provide Info for my talk!
On Tue, Feb 19, 2013 at 3:15 PM, Allan McRae al...@archlinux.org wrote: I am giving an hour long talk at the end of next week about Arch, how it works and why we are successful. I will focus on stuff I am involved with (i.e. pacman...), but will give examples of things like how we decided on systemd, the new installer, etc. (other suggestions welcome) I'm doing a similar thing in Paris at the beginning of April, so I'll be asking Allan for whatever off-list feedback you give so I can steal it :) Finally, if you are in Lisbon on the 1st of March, come see me! Search for SINFO XX for details. Also, if anyone are in Paris on the fourth and fifth of April, please come say hi (I'll post a link once the conference is announced). Cheers, Tom
Re: [arch-dev-public] mesa packaging, libGL handling
On Fri, Feb 15, 2013 at 7:05 PM, Jan Steffens jan.steff...@gmail.com wrote: On Fri, Feb 15, 2013 at 5:10 PM, Laurent Carlier lordhea...@gmail.com wrote: Perhaps we could merge: - mesa, khrplatform-devel - libglapi, libgl, libgles - libgbm, libegl Also, the pipe drivers from libgbm should be sorted into the *-dri packages. Out of curiosity, what would be the benefit of keeping it split up rather than just merging (almost) everything? -t
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Tue, Feb 12, 2013 at 5:42 PM, Andreas Radke andy...@archlinux.org wrote: Am Sat, 9 Feb 2013 17:35:27 +0100 schrieb Andreas Radke andy...@archlinux.org: Since cairo will also depend on that libegl then every system will pull in Wayland. Is this really needed? If we can't build it in a different way we directly need to move Wayland to extra. -Andy Bump. If we agree that we want to start to support Wayland in Arch we need to move Wayland libs to the extra repo. Then I can build Mesa making use of it in libegl. This shouldn't harm anything else and wayland libs are a pretty small pkg (when we drop the static libs). So who's going to move it to extra and wants to maintain it there? I could build it but will not use it myself anytime soon. I'll be happy to maintain Wayland, so I'll take it over and move it to [extra]. -t
[arch-dev-public] Bluez5.X
Hi guys, Another update on the Bluez front. I will, as advised by upstream, ship it as a split package, which should hopefully help with the transition. There will be the 'bluez' package containing the bluez and obex daemons, as well as a couple of universally useful tools. Packages that depend on the dbus interface exposed by the bluez daemon will need extra care in transitioning from 4.X to 5.X as compatibility has been broken. There will be the 'bluez-libs' package which splits out the deprecated libraries. These are going away eventually (6.X/7.X?), but for the time being they are backwards compatible with the libs shipped in 4.X, which means that any package that only depends on the libs will be unaffected by the transition to 5.X. Lastly, there will be the 'bluez-utils' package containing all the tools that are not really useful unless you are a developer or doing debugging. Splitting them out makes things much simpler IMHO, as it is clear that all these things can be ignored by most users. Please find the proposed package-build attached. Comments welcome. Cheers, Tom PKGBUILD Description: Binary data
Re: [arch-dev-public] [RFC] Add Wayland/Weston
Hi Sébastien, Thanks for bringing this up! On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer se...@seblu.net wrote: If the both maintainers agreed to add support, we need to find a gentle developper which can move wayland to extra[5]. I'd be happy to take wayland to extra when the time comes. Just let me know when you think it is ready. As long as there are no objections from mesa/cairo maintainers that is. Cheers, Tom
Re: [arch-dev-public] kdelibs / docbook-xsl
Please someone move it. Im not at home at the moment. T On Feb 8, 2013 12:01 PM, Ike Devolder ike.devol...@gmail.com wrote: Hi, Is there something stopping us moving docbook-xsl and co to extra, kdelibs 4.10.0-2 references to is and is already moved to extra thx -- Ike
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Feb 8, 2013 2:56 PM, Jan de Groot j...@jgc.homeip.net wrote: On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: I appreciate your effort and have no objection against adding Wayland. However, to limit people's enthusiasm about this, I just want to remark that having Wayland installed now is not incredibly useful: Weston is AFAIK the only compositor available at this time, and it is, as you mention, a demo (there was talk of some tiling WM being ported to Wayland, I forgot the name). Also you'll use XWayland most of the time. When Qt5 gets released and Qt4 applications are ported (which will likely happen for all Qt4 applications), there'll be at least many applications that can use Wayland natively. When KDE is ported to Qt5, we'll also get kwin as a more feature-rich Wayland compositor. I didn't read about the GTK situation yet, but I guess GTK3 has Wayland support already. This is my main concern for Wayland at this moment. Though it looks cool to support new technology and having released versions of Wayland with 1.x versioning, I doubt there's much use for it at this moment. Running X inside of wayland is a nice feature for apps that aren't ported yet, but if you only run apps that aren't ported yet, there's no use for Wayland at the moment. Thomas and Jan are right, Wayland does not provide much at the moment. However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends. Cheers, Tom
Re: [arch-dev-public] [RFC] Add Wayland/Weston
On Feb 8, 2013 2:56 PM, Jan de Groot j...@jgc.homeip.net wrote: On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote: I appreciate your effort and have no objection against adding Wayland. However, to limit people's enthusiasm about this, I just want to remark that having Wayland installed now is not incredibly useful: Weston is AFAIK the only compositor available at this time, and it is, as you mention, a demo (there was talk of some tiling WM being ported to Wayland, I forgot the name). Also you'll use XWayland most of the time. When Qt5 gets released and Qt4 applications are ported (which will likely happen for all Qt4 applications), there'll be at least many applications that can use Wayland natively. When KDE is ported to Qt5, we'll also get kwin as a more feature-rich Wayland compositor. I didn't read about the GTK situation yet, but I guess GTK3 has Wayland support already. This is my main concern for Wayland at this moment. Though it looks cool to support new technology and having released versions of Wayland with 1.x versioning, I doubt there's much use for it at this moment. Running X inside of wayland is a nice feature for apps that aren't ported yet, but if you only run apps that aren't ported yet, there's no use for Wayland at the moment. Thomas and Jan are right, Wayland does not provide much at the moment. However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends. Cheers, Tom
Re: [arch-dev-public] JAVA_HOME in systemd
On Feb 6, 2013 3:09 PM, Guillaume ALAUX guilla...@archlinux.org wrote:
On 6 February 2013 15:08, Guillaume ALAUX guilla...@archlinux.org wrote:
-- Forwarded message --
From: Leonidas Spyropoulos artafi...@gmail.com
Date: 6 February 2013 14:52
Subject: Re: [arch-dev-public] JAVA_HOME in systemd
To: guilla...@archlinux.org
On Wed, Feb 6, 2013 at 1:36 PM, Jan Steffens jan.steff...@gmail.com
wrote:
On Wed, Feb 6, 2013 at 1:58 PM, Gaetan Bisson bis...@archlinux.org
wrote:
You can always have each Java runtime provide a different file, and
include all of them in each Java service file using
EnvironmentFile=-/path/to/java/runtime/number/one
EnvironmentFile=-/path/to/java/runtime/number/two
etc.
You can also pass a wildcard expression, avoiding hardcoding several
files,
maybe like this:
EnvironmentFile=-/etc/java-runtime.d/*
EnvironmentFile=-/etc/java-runtime
Needs testing, but could allow the user to set a default runtime via
symlink.
Alternatively, just EnvironmentFile=/etc/java-runtime and create this
symlink
at post_install of every java-runtime, if it doesn't exist already.
To be tidy, post_remove then deletes the file if java-runtime.d
doesn't exist anymore.
I can't send to mailing list as I am not a dev / TU.
Isn't it possible to detect the JDK on runtime? Getting it from the
java command? (or the javac command)
--
Caution: breathing may be hazardous to your health.
#include stdio.h
int main(){printf(%s,\x4c\x65\x6f\x6e\x69\x64\x61\x73);}
The point is to enable the user to statically set which JRE must be
used. Detecting it at each java app runtime would not be ideal.
And I'd also rather not have to list all potential JRE in all java
systemd files.
Creating a symlink at post_install if it does not already exist looks
nice to me.
The symlink seems reasonable to me. It would be nice if all the
distros/upstreams could agree on a scheme though as this does not sound
Arch/systemd specific.
Cheers,
Tom
Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts
On Mon, Feb 4, 2013 at 3:00 AM, Dan McGee dpmc...@gmail.com wrote: * s/announced previously/previously announced/ * still using them (instead of 'it') Thanks. Announcement posted. Will create todo and remove packages sometime today. Cheers, Tom
Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts
On Sun, Feb 3, 2013 at 12:18 PM, Pierre Schmitz pie...@archlinux.de wrote: No objections. Will you make a TODO list to remove the remaining files in /etc/rc.d? Maybe have a look at /etc/conf.d as well so we finally get consistent here. Will do both. I suggest the following announcement (feel free to improve the wording): ===8=== Final sysvinit deprecation warning As announced previously, initscripts are no longer receiving any testing and support has been dropped from various packages. Any users still using it should switch to systemd. initscripts, sysvinit and the various rc scripts are being removed from the repositories to avoid any confusion about their status. ===8=== -t
Re: [arch-dev-public] [RFC] Finally dropping initscripts and rc scripts
On Sat, Feb 2, 2013 at 12:18 AM, Tom Gundersen t...@jklm.no wrote: To make our communication with our users clear I suggest we drop initscripts I guess we should also drop 'sysvinit' and only keep 'sysvinit-tools' to avoid any confusion. -t
Re: [arch-dev-public] Silent removal of initscripts?
On Mon, Jan 28, 2013 at 4:46 PM, Dan McGee dpmc...@gmail.com wrote: I know we posted a news item back in November about the deprecation of old school rc.d scripts, but the current silent removal thing is not real cool, and one never knows what package is going to fail to start up next. Last week it was openvpn, today it appears samba has lost its script. As there has been no announcement of anyone taking responsibility for the rc scripts, I'd assume that anyone still using them are basically on their own now. We should post a news item saying scripts are disappearing as of now, please be aware, as any machine booted remotely gives absolutely zero indication that some service startup failed until you try to actually use the service. Makes sense. Also, rumor has it a community package exists to catalog these old rc.d scripts once they are removed, but `pacman -Ss initscripts` and `pacman -Ss rc.d` found me nothing. Giving our users (and hell, other developers) at least a bit of heads up would be awesome here. I know Lukas intended to do something along these lines, and indeed there is a repository [0], but apparently it is not shipped as a package (yet?). Lukas, what is your plan with this? It would be good to know if and how you intend to deal with this stuff and include it in the announcement. IMNSHO, it would probably be best to just unequivocally declare the rc scripts as dead and unsupported rather than try to play catch-up now. Official rc scripts support is really something we should have discussed and planned in December, not a month after things stopped working... Cheers, Tom [0]: https://projects.archlinux.org/svntogit/community.git/tree/sysvinit-scripts/trunk.
Re: [arch-dev-public] filesystem package
On Sun, Jan 27, 2013 at 1:55 AM, Allan McRae al...@archlinux.org wrote:
Anyway, I say we can just remove post_install from filesystem and reduce
the dependencies to only iana-etc
Yes please. This has long been on my low-priority TODO.
, and then make glibc depend on
filesystem. We can assume coreutils and bash are installed before an
upgrade of filesystem.
Yup. For post_upgrade we can depend on 'base' being installed.
Lets see what is in filesystem's post_install:
post_install() {
[ -f var/log/lastlog ] || : var/log/lastlog
Either just remove (not sure why it is needed, didn't check), or move
to shadow as you propose.
[ -f var/log/wtmp ]|| : var/log/wtmp
[ -f var/log/btmp ]|| { : var/log/btmp chmod 600
var/log/btmp; }
Not needed. Done by /usr/lib/tmpfiles.d/systemd.conf
# workaround for bug #7194
# readded due to bug #9465
# please do not remove!
chmod 1777 var/spool/mail tmp var/tmp
}
The chmod part can be removed (despite the warning). It was initially a
bug in pacman and then the installer. Given pacman has been fixed for
years and we just use pacman -r for the installer, there is no need
for that. This is entirely the wrong place to fix this non-existent bug.
Great!
That leaves the initialising of log files. I guess the lastlog one
should be moved to the shadow package. Definitely not the job of
filesystem. I am not sure what package should do the wtmp and btmp
ones. Anyone know?
As stated above: just remove it.
-t
Re: [arch-dev-public] Winter Cleanup of [extra]
On Thu, Jan 24, 2013 at 4:08 PM, Andrea Scarpino and...@archlinux.org wrote: bluez-hcidump I adopted this. It will go away with the next bluez release. Cheers, Tom
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae al...@archlinux.org wrote: There is nothing stopping us dropping vi completely and just putting vim on the install media... I'd favor that (as a vim user who always gets confused by vi on the install media). -t
Re: [arch-dev-public] systemd 197 - kdm fails
I'm using KDE as well, but have not been able to reproduce this problem. Any chance you could get some more debug info out of it? Sounds like something times out... On Fri, Jan 11, 2013 at 6:17 PM, Lukas Jirkovsky l.jirkov...@gmail.com wrote: On 8 January 2013 10:27, Thomas Bächler tho...@archlinux.org wrote: First of all, sorry for my recent absence, I was hoping to spend some time on Arch over Christmas, which I didn't. Anyway, today's systemd upgrade causes a problem which I was only able to solve by downgrading: When systemd launched kdm.service, X started, but the kdm greeter never appeared - instead X just sat there with the busy mouse pointer. systemctl stop kdm.service hung too, I could only kill -9 the X process. When I downgraded to 196-2, the greeter started immediately after the systemctl daemon-reexec in post_upgrade. I have no idea where to start, so any help is appreciated. Even worse: After the downgrade, systemctl start /boot (and thus the automounter) didn't work, I had to mount /boot manually. Today I have accidentally upgraded to systemd 197 (I was trying to avoid it because of this email). I can partially confirm this problem – after booting it takes quite some time (probably a few minutes) before X pops up. When the X finally starts, it shows the busy mouse pointer as you mentioned. However, for me KDM starts, even though it takes a while. Lukas
Re: [arch-dev-public] network interface naming with systemd 197
On Jan 6, 2013 7:38 PM, Dave Reisner d...@falconindy.com wrote:
Just an FYI:
Upstream pushed a commit[0] which gives network devices persistent, and
unique, names based on hardware attributes, avoiding the random kernel
names. While this solves a real problem, it's also a fairly jarring
change. For example:
$ udevadm info /sys/class/net/eth0
P: /devices/pci:00/:00:1c.2/:05:00.0/net/eth0
E: DEVPATH=/devices/pci:00/:00:1c.2/:05:00.0/net/eth0
E: ID_BUS=pci
E: ID_MODEL_ID=0x4364
E: ID_NET_NAME_MAC=enxbcaec50bfcc8
E: ID_NET_NAME_PATH=enp5s0
E: ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_PRODUCT_FROM_DATABASE=88E8056 PCI-E Gigabit Ethernet Controller
E: ID_VENDOR_FROM_DATABASE=Marvell Technology Group Ltd.
E: ID_VENDOR_ID=0x11ab
E: IFINDEX=2
E: INTERFACE=eth0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: USEC_INITIALIZED=42063
If I were to reboot right now (systemd-git), eth0 would become enp5s0. I
tend to think that this is fairly extreme, and would throw off a lot of
people -- especially those who never needed to deal with interface
renaming.
For systemd 197, I plan on shipping this rule as documentation in
/usr/share/doc/systemd and _not_ enabling it by default. Those who want
to opt in can simply copy the rule to /etc/udev/rules.d. They can also,
of course, continue to use whatever MAC-based rules they might have, but
I would strongly recommend switching these rules to be triggered by
ID_NET_NAME_{SLOT,PATH,ONBOARD} instead.
Cheers,
Dave
[0] http://cgit.freedesktop.org/systemd/systemd/commit/?id=394e2938ff9
How about:
1) follow upstream on fresh installs (i.e. ship the rule and don't mask it
in post_instal).
2) stay backwards compatible on upgrade (i.e. mask the rule in
post_upgrade).
3) print a notice about the masking so people can unmask it.
4) rather than a symlink to null, use an empty rules file with a comment
explaining why it is there and what will happen if you delete it.
Cheers,
Tom
[arch-dev-public] [BlueZ 5.0] minimum kernel version bump
Hi guys, BlueZ 5.0 has been released [0], which is incompatible with 4.X. For this reason I won't be pushing the release until all dependent packages are ready. Once this release is out, it will bump the minimum kernel requirement of BlueZ to 3.4, so users of the LTS kernel should be aware that this will not work. Cheers, Tom [0]: http://www.bluez.org/release-of-bluez-5-0/
Re: [arch-dev-public] [RFC] dbus cleanup
On Mon, Dec 3, 2012 at 11:55 AM, Dave Reisner d...@falconindy.com wrote: On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote: On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote: While we're touching the PKGBUILD, why do we fix the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me). Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past. Good point, actually. I've been doing the same myself. $ grep NoExtract /etc/pacman.conf NoExtract= etc/X11/xinit/xinitrc.d/30-dbus For the record: removing this file caused some issues, so I reinstated it. I expect it will all become redundant in the not too distant future (due to systemd --user), but let's just leave it alone for now. -t
Re: [arch-dev-public] [RFC] dbus cleanup
On Mon, Dec 3, 2012 at 10:07 AM, Jan de Groot j...@jgc.homeip.net wrote: On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote: While we're touching the PKGBUILD, why do we fix the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me). Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past. I'll make this and the other changes and push to testing. Cheers, Tom
Re: [arch-dev-public] [RFC] dbus cleanup
On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae al...@archlinux.org wrote: Some fun here... (1/1) removing dbus-core [##] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly Obviously nothing to be concerned about... Oh, nice... I don't know why I didn't get that message. Anyway, it is not a problem. If for some reason the removal should work, then the user/group will be added back immediately by the dbus upgrade. Any suggestions on how these messages can be avoided? -t
Re: [arch-dev-public] [RFC] dbus cleanup
On Dec 3, 2012 2:43 PM, Jan de Groot j...@jgc.homeip.net wrote: On ma, 2012-12-03 at 13:05 +0100, Tom Gundersen wrote: Any suggestions on how these messages can be avoided? You can't, unless you push an update for dbus-core first... There is no way to enforce that people update dbus-core first, so I think we'll just have to live with the warning. To make sure this is the last time this happens, I'll move the user/group to filesystem as Dave suggested. Cheers, Tom
[arch-dev-public] [RFC] the future of /media
Hi guys, With udisks2 being used by gnome, and about to be used by the next KDE, some people have raised concerns about the transition from udisks1 to udisks2. The issue is: udisks1 mounts your devices to /media, whereas udisks2 will mount them to /run/media/$user. There are very good reasons for this change (mainly security), but the fact remains that it causes problems on upgrade for people who have hard-coded these paths [0]. On a single-user system, the problem could simply be solved by symlinking /media to /run/media/$user. On multi-user systems one would have to add one symlink per device to /media. Either way, this is something the local admin would have to deal with and not anything we can do. What we can do, however, is to avoid problems on upgrades of the filesystem package by not shipping /media on udisks1-free systems. I suggest that we move /media from the filesystem to the udisks package, allowing everyone else to do what they wish locally. We would also need to post a news item (hopefully not quite as rambling as this email) explaining what has happened and what people might want to do. Comments? Cheers, Tom PS This problem is probably a lot smaller than it appears, as our gnome packages made the switch to udisks2 quite some time ago, but at least I have not seen any serious bug reports until now. [0]: https://bbs.archlinux.org/viewtopic.php?pid=1197065#p1197065
Re: [arch-dev-public] [RFC] the future of /media
On Thu, Nov 22, 2012 at 2:53 PM, Tom Gundersen t...@jklm.no wrote: I suggest that we move /media from the filesystem to the udisks package, allowing everyone else to do what they wish locally. I implemented this in the packages in [testing], so people can have a look. Cheers, Tom
Re: [arch-dev-public] Clarity about initscripts and systemd status
On Sat, Nov 3, 2012 at 5:16 PM, Tom Gundersen t...@jklm.no wrote: As systemd is now the default init system, Arch Linux is receiving minimal testing on sysvinit/initscripts systems. Due to a lack of resources and interest, sysvinit/initscripts-specific bugs may now be closed as WONT FIX. We therefore strongly encourage all users to migrate to systemd as soon as possible: link to guide. For the time being, sysvinit/initscripts support will remain in the official repositories, unless otherwise stated. As of January 2013, sysvinit/initscripts support may be removed from individual packages without further notice. Unless there are any objections, I'll put this up soon so I can start closing bugs without feeling bad about it ;-) -t
Re: [arch-dev-public] Clarity about initscripts and systemd status
On Sun, Nov 4, 2012 at 4:51 PM, Andreas Radke andy...@archlinux.org wrote: Unless there are any objections, I'll put this up soon so I can start closing bugs without feeling bad about it ;-) -t +1 -Andy Done. -t
Re: [arch-dev-public] Clarity about initscripts and systemd status
On Sat, Nov 3, 2012 at 4:34 PM, Pierre Schmitz pie...@archlinux.de wrote: * Publish an announcement with the said dates and a link to a migration guide * Support for initscripts can be dropped e.g. end of December. After that packages may drop support; but not before. * rc.d scripts and other related files should be removed by end of January. This makes it easier for third party repos to provide a package containing all the rc scripts. Similar to what we had before systemd got officially supported. What do you think? I agree that we should make an announcement. My suggestion would be something along these lines: As systemd is now the default init system, Arch Linux is receiving minimal testing on sysvinit/initscripts systems. Due to a lack of resources and interest, sysvinit/initscripts-specific bugs may now be closed as WONT FIX. We therefore strongly encourage all users to migrate to systemd as soon as possible: link to guide. For the time being, sysvinit/initscripts support will remain in the official repositories, unless otherwise stated. As of January 2013, sysvinit/initscripts support may be removed from individual packages without further notice. As to forcibly removing all the rc scripts by a certain date, I guess we could get back to that later once we see how things pan out? I'd be fine with doing it, but don't see the urgency. -t
Re: [arch-dev-public] Issues with kernel 3.6.4 on some AMD systems
On Fri, Nov 2, 2012 at 8:06 PM, Pierre Schmitz pie...@archlinux.de wrote: turns out there was an issue with Linux 3.6.4 on some AMD systems with more than 4GB of RAM. 3.6.5 fixed this bug. Unfortunately this was a little too late for the recent ISO image. I was wondering what was the best way to handle issues like this. Maybe in this case it is not worth it, but in principle we could just push a new version (not changing anything but bumping the kernel version). -t
Re: [arch-dev-public] Fwd: NetworkManager starts dhclient with a bad path to lease file
On Thu, Nov 1, 2012 at 10:27 PM, Jan Steffens jan.steff...@gmail.com wrote: should we change dhcp and dhclient to use /var/lib instead of /var/state? AFAICT it's the only package using the /var/state directory. Context below. Seems reasonable to me. /var/state is not a standard dir afaik, and /var/lib should contain variable state information according to FHS (which I shamelessly cite exactly when it supports my view). -t
[arch-dev-public] libtirpc
Hi guys, This is just a note so I/we don't forget: When the next libtirpc release comes out we need to treat it as an soname bump and do a full rebuild. This is due to ABI being introduced in -rc1 and removed in -rc3 (we are currently on -rc2). This was discussed upstream, and the decision was to not bump the soname as the ABI break does not affect proper releases. Cheers, Tom
Re: [arch-dev-public] libtirpc
On Fri, Nov 2, 2012 at 12:13 AM, Dave Reisner d...@falconindy.com wrote: On Thu, Nov 01, 2012 at 11:24:01PM +0100, Tom Gundersen wrote: Hi guys, This is just a note so I/we don't forget: When the next libtirpc release comes out we need to treat it as an soname bump and do a full rebuild. This is due to ABI being introduced in -rc1 and removed in -rc3 (we are currently on -rc2). What was the motivation to package rc2? Why did we package an RC at all? https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/libtirpcid=9a41e99b108cd Not very descriptive... I don't know. Tobias? -t
Re: [arch-dev-public] Dropping all packages with missing systemd units
On Wed, Oct 31, 2012 at 11:57 AM, Alexander Rødseth rods...@gmail.com wrote: I can adopt and add systemd support for noip and pdns if they are orphaned (and pdns is moved to [community]). Pierre, Jan: unless you object I'll move pdns to community so Alexander can take it over. Alexander: Would you like to take over pdns-recursor too? As to noip, as it is already in community and has been on the TODO for ages, you might as well add yourself as co-maintainer and update it. -t
