Re: [arch-general] GNOME Software: Status and integrable?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/25/2014 08:43 PM, Armin K. wrote: On 03/26/2014 01:26 AM, Karol Babioch wrote: Hi, now that GNOME 3.12 has been released and probably will hit the repos in the next couple of days/weeks, I'm wondering what the current status of Software is [1]? This is an application similar to an app store in the mobile world. I couldn't find it in the repos, and I wouldn't expect it to even work without some patching, because obviously it would have to be integrated into the packet management system. The only reference I could find in regards to Arch Linux was a forum thread from last year [2], which basically ended up in a mess without any real answers. On the other hand I may have missed it, because GNOME is really good in using generic terms like Software and Web to name their applications, which are not great to search for :'(. I'm not interested in another flame war about GNOME, when it hits the repos and things like that. I just want to know whether this particular application is available/works and if not what the technical hurdles would be to make it work and whether it is feasible to get it working in the near term. Arguably users of Arch Linux are expected to know how to use use the command line (including pacman) and I'm fine with that, but I wouldn't mind to be able to browse an app store, just for the fun of it ;). Best regards, Karol Babioch [1]: https://wiki.gnome.org/Design/Apps/Software [2]: https://bbs.archlinux.org/viewtopic.php?id=170223 Not that I am much aware of the state of this, but from what I've seen, the package requires packagekit. Archlinux packagekit package is fairly old and I doubt that it can be used by gnome-software. There was a thread on one of archlinux mailing lists regarding packagekit not so long ago, but even after that thread, packagekit still remained at version 0.7 which was released 2 years ago, while 0.8 (maybe even 0.9) is the latest available version. Salutations, I can't find that thread, can you point me to it? Since Arch is bleeding edge, it's a bit strange for a package to be that out of date. Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMyd5oACgkQZ/Z80n6+J/aosQD+PXKMQn50IbZN3z9K3hngxLnM 9Fy8K+J0vahD1D+VXPEA/3eMZH4g0Us8td7KL8FjBXlhorgXhn/TAZ28uo56SJQ/ =9EuZ -END PGP SIGNATURE-
Re: [arch-general] GNOME Software: Status and integrable?
On 26/03/14 02:45 AM, Mark Lee wrote: On 03/25/2014 08:43 PM, Armin K. wrote: On 03/26/2014 01:26 AM, Karol Babioch wrote: Hi, now that GNOME 3.12 has been released and probably will hit the repos in the next couple of days/weeks, I'm wondering what the current status of Software is [1]? This is an application similar to an app store in the mobile world. I couldn't find it in the repos, and I wouldn't expect it to even work without some patching, because obviously it would have to be integrated into the packet management system. The only reference I could find in regards to Arch Linux was a forum thread from last year [2], which basically ended up in a mess without any real answers. On the other hand I may have missed it, because GNOME is really good in using generic terms like Software and Web to name their applications, which are not great to search for :'(. I'm not interested in another flame war about GNOME, when it hits the repos and things like that. I just want to know whether this particular application is available/works and if not what the technical hurdles would be to make it work and whether it is feasible to get it working in the near term. Arguably users of Arch Linux are expected to know how to use use the command line (including pacman) and I'm fine with that, but I wouldn't mind to be able to browse an app store, just for the fun of it ;). Best regards, Karol Babioch [1]: https://wiki.gnome.org/Design/Apps/Software [2]: https://bbs.archlinux.org/viewtopic.php?id=170223 Not that I am much aware of the state of this, but from what I've seen, the package requires packagekit. Archlinux packagekit package is fairly old and I doubt that it can be used by gnome-software. There was a thread on one of archlinux mailing lists regarding packagekit not so long ago, but even after that thread, packagekit still remained at version 0.7 which was released 2 years ago, while 0.8 (maybe even 0.9) is the latest available version. Salutations, I can't find that thread, can you point me to it? Since Arch is bleeding edge, it's a bit strange for a package to be that out of date. Regards, Mark You're welcome to add a libalpm backend to a newer version of PackageKit if you think it's worth your time. signature.asc Description: OpenPGP digital signature
Re: [arch-general] GNOME Software: Status and integrable?
On Wed, Mar 26, 2014 at 01:43:57AM +0100, Armin K. wrote: On 03/26/2014 01:26 AM, Karol Babioch wrote: Hi, now that GNOME 3.12 has been released and probably will hit the repos in the next couple of days/weeks, I'm wondering what the current status of Software is [1]? This is an application similar to an app store in the mobile world. I couldn't find it in the repos, and I wouldn't expect it to even work without some patching, because obviously it would have to be integrated into the packet management system. The only reference I could find in regards to Arch Linux was a forum thread from last year [2], which basically ended up in a mess without any real answers. On the other hand I may have missed it, because GNOME is really good in using generic terms like Software and Web to name their applications, which are not great to search for :'(. I'm not interested in another flame war about GNOME, when it hits the repos and things like that. I just want to know whether this particular application is available/works and if not what the technical hurdles would be to make it work and whether it is feasible to get it working in the near term. Arguably users of Arch Linux are expected to know how to use use the command line (including pacman) and I'm fine with that, but I wouldn't mind to be able to browse an app store, just for the fun of it ;). Best regards, Karol Babioch [1]: https://wiki.gnome.org/Design/Apps/Software [2]: https://bbs.archlinux.org/viewtopic.php?id=170223 Not that I am much aware of the state of this, but from what I've seen, the package requires packagekit. Archlinux packagekit package is fairly old and I doubt that it can be used by gnome-software. There was a thread on one of archlinux mailing lists regarding packagekit not so long ago, but even after that thread, packagekit still remained at version 0.7 which was released 2 years ago, while 0.8 (maybe even 0.9) is the latest available version. -- Note: My last name is not Krejzi. Note on packagekit: The guys at Antergos started the port of the alpm backend to 0.8 but it seems it's a lot more work than first anticipated. Currently I don't have sufficient time to digg into this myself to get our alpm backend on par with the latest packagekit again. -- Ike pgp6im23pOCr5.pgp Description: PGP signature
Re: [arch-general] What's with F# and mono?
On Tue, Mar 25, 2014 at 4:55 PM, Magnus Therning mag...@therning.orgwrote: I'm just starting to dip my toes in the mono waters. Slightly prompted by my current situation at work. In particular I'm interested in F#, but I'm finding the whole situation around mono/monodevelop + F# a bit confusing. 1. There are indications online that mono ships with F# [^1][^2]. But the mono package in Arch doesn't include F#. Looking at the sources used to build the mono package there is no F# in sight. Was it ever there? 2. The package on AUR[^3] for fsharp is rather outdated. Not such a big problem, the building received a lot of TLC so the package is extremely simple to bring up-to-date. 3. Is there an F# add-in for monodevelop? There seems to have been one back in 2010, but it's not distributed any more, [^4]. However, other places say there is an add-in available, [^5] (however, downloading fails). So, can anyone help me get a clearer picture of F# on mono (and ArchLinux)? /M [^1]: http://tirania.org/blog/archive/2010/Nov-11.html - talking of plans to include F# in mono. [^2]: http://is.gd/cNC5xb- - F# is included in the standard Mono release, but it's still missing from the MonoDevelop IDE. [^3]: https://aur.archlinux.org/packages/fsharp/ [^4]: http://is.gd/YndnsA- - bug on F# add-in missing, closed for MD 2.4, the last comment suggests it'd be re-opened [^5]: http://is.gd/YndnsA- which links to http://addins.monodevelop.com/Project/Index/48 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich I had this running in Arch using the packages from the standard repositories several months ago (new system since then). I had to compile and install F# manually from [1]. If memory serves, I had to install an add-on/plug-in in mono develop for F# support to work. [1] https://github.com/fsharp/fsharp Thanks Squall -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N https://github.com/headmastersquall
[arch-general] Trimming down our default kernel configuration
Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without enabling CONFIG_EXPERT. I have no idea what the impact of this option is, other than that it was requested in order to support some tool that can freeze and save single processes resume them later. I am generally sceptical towards options that require CONFIG_EXPERT, so I propose dropping this one, too. 3) We enable tons of debug options in the Kernel Hacking section, many of which have a small performance impact. I'd like to get rid of those that we don't need (I didn't go through all of them yet). What I'd like is a discussion where people suggest more things that could or should be dropped, and tell me what is absolutely needed and why. I hope that such a discussion makes it clearer to me how I should proceed. Regards Thomas signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 19:56:26 +0100 Thomas Bächler tho...@archlinux.org wrote: Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. Thanks for doing this. 1) Once we agreed to disable one LSM, everyone else said we can enable LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. I agree regarding SELinux/Apparmor (it's not only userspace tools, but also sane application policies that are missing). However, I don't think that Yama requires any userspace components, does it? Currently, I boot with security=yama and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without enabling CONFIG_EXPERT. I have no idea what the impact of this option is, other than that it was requested in order to support some tool that can freeze and save single processes resume them later. I am generally sceptical towards options that require CONFIG_EXPERT, so I propose dropping this one, too. 3) We enable tons of debug options in the Kernel Hacking section, many of which have a small performance impact. I'd like to get rid of those that we don't need (I didn't go through all of them yet). What I'd like is a discussion where people suggest more things that could or should be dropped, and tell me what is absolutely needed and why. I hope that such a discussion makes it clearer to me how I should proceed. Regards Thomas Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
Am 26.03.2014 20:18, schrieb Leonid Isaev: However, I don't think that Yama requires any userspace components, does it? Currently, I boot with security=yama and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Wed, 26 Mar 2014 21:00:15 +0100 Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 20:18, schrieb Leonid Isaev: However, I don't think that Yama requires any userspace components, does it? Currently, I boot with security=yama and completely disabled non-admin ptrace (kernel.yama.ptrace_scope=2). Perhaps -ARCH kernels should keep Yama available albeit disabled by default (as they now do). Once yama is built-in, the ptrace_scope protection is enabled by default. There is no option to change that. But by default, kernel.yama.ptrace_scope = 0, which according to documentation (Yama.txt) is like having no ptrace restriction at all, and indeed gdb/strace work... Best, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Configuring enabled services
On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman akleiner...@buinet.com.ar wrote: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages Regards, Ary Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. Finally, systemctl list-unit-files will list all unit files with their enabled/disabled/static status, where static means that they run by default (when pulled in) and disabled means they can be installed - that is, they have an [Install] section - but haven't been yet. And systemctl enable/disable manages the symlinks under /etc/systems/system specified by the [Install] section. Is my understanding of the situation correct? Thanks, Gesh
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On 26/03/14 02:56 PM, Thomas Bächler wrote: Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. I think we should drop x32 support if no one is planning on packaging the minimum of a compiler and standard C library. It's cool, but no one appears to be very interested in using it in the real world. You would probably get bigger wins from recompiling with -march=native, so I somewhat doubt that anyone grasping for the last bit of performance will use our binaries anyway. This was already responsible for a security vulnerability in Arch: http://seclists.org/oss-sec/2014/q1/187 signature.asc Description: OpenPGP digital signature
Re: [arch-general] Configuring enabled services
That is correct, when you call `systemctl enable foo.unit` then the [Install] section of the unit file is executed. Static means that the unit has no [Install] section, meaning it is permanently enabled/disabled as far as the systemctl enable/disable tool is concerned. Other than pulling themselves in when other units start, a unit can also symlink another unit name to itself using the Alias= option, and specify other units to enable/disable as a group using the Also= option. On 27 March 2014 07:13, Gesh g...@gesh.uni.cx wrote: On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman akleiner...@buinet.com.ar wrote: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages Regards, Ary Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. Finally, systemctl list-unit-files will list all unit files with their enabled/disabled/static status, where static means that they run by default (when pulled in) and disabled means they can be installed - that is, they have an [Install] section - but haven't been yet. And systemctl enable/disable manages the symlinks under /etc/systems/system specified by the [Install] section. Is my understanding of the situation correct? Thanks, Gesh
Re: [arch-general] Configuring enabled services
On Thu, Mar 27, 2014 at 12:13:08AM +0200, Gesh wrote: On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman akleiner...@buinet.com.ar wrote: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages Regards, Ary Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Systemd builds a dependency tree, starting at the initial boot target. This target is usually called default.target. From there, dependencies are pulled in based on the deps listed in the various targets. Some targets, such as multi-user.target, specify a folder called multi-user.target.wants that contains units that the target wants, i.e. are soft dependencies of it. So to enable a unit on startup, it needs to be made a dependency (either a want or a need) of a target that is pulled in by the boot dependency tree. Those symlinks in the [Install] section add the unit to the dependency list of the folder's unit. (This is usually multi-user.target). But units do not _need_ this type of symlink to be pulled in. If a dependency is hard-coded into a unit that is part of the startup tree, it will be started. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. There's nothing special about symlinks, as I mentioned above. But yes, if a package wants to have itself enabled on boot by default, it can insert a symlink to its unit file into the .wants folder in /usr/lib/systemd/system. Finally, systemctl list-unit-files will list all unit files with their enabled/disabled/static status, where static means that they run by default (when pulled in) and disabled means they can be installed - that is, they have an [Install] section - but haven't been yet. And systemctl enable/disable manages the symlinks under /etc/systems/system specified by the [Install] section. Is my understanding of the situation correct? As for the static/active/disabled terminology, see [1]. The systemctl enable/disable thing is just a handy way of managing the symlinks. If a unit does not have an [Install] section, systemctl enable/disable will do nothing. The unit can still be enable by manually symlinking, of course. Thanks, Gesh Hope this helped. --Sean [1] https://bbs.archlinux.org/viewtopic.php?pid=1153751#p1153751
[arch-general] Gnome-shell Compositing for full screen applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Salutations, I was recently running a test of the i3 windows manager and tried dolphin-emu. To my surprise I was able to play Wii games at full speed at 1080p resolution on my i3-2105 (Intel HD 3000) rig. I'm assuming this is due no compositing in i3. With that in mind, I was wondering if there was a way to make gnome-shell disable compositing for full screen applications. Regards, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlMziXkACgkQZ/Z80n6+J/am+AEAhbnWcpS5TVbhomZogRI3z/Hg cKUau/u6/hkYQjOBlWsA/RoVShK5GXWAMrtvsaG0a/zmUJ1W1rKuXRKkT6HO0SyU =lNLz -END PGP SIGNATURE-
