- Arch-general - lists.archlinux.org

[arch-general] svntogit interface issue
by Leonid Isaev 26 Dec '13

26 Dec '13

Hi, I just noticed that svntogit interface at archlinux.org is few days behind SVN. For example systemd is still listed in trunk with pkgrel=5, while [testing] has pkgrel=9. Is this a known problem? Thanks and happy holidays, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

1 0

[arch-general] -Bsymbolic-functions
by Olivier Langlois 26 Dec '13

26 Dec '13

>From https://sourceware.org/binutils/docs/ld/Options.html#Options -Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries. I have discovered this ld switch by seeing it offered in the alsa-lib configure script: --enable-symbolic-functions use -Bsymbolic-functions option if available (optmization for size and speed) My limited knowledge of how shared libraries work is that code refering to a 'so' function jump in a location containing a second jump to the address of the loaded symbol and this second jump instruction gets patched when the 'so' is loaded. So my understanding of the switch is that activating just go directly to the function without any indirection. Could it be interesting to make this switch standard in makepkg.conf? Has this ever been discussed in the past? The only potential problem that I can foresee with its usage is for programs 'hijacking' symbols by being preloaded first. The 2 programs that I know doing this are: trickle and glc but I am sure that there are many others.

1 0

Re: [arch-general] [arch-dev-public] [HEADSUP] Arch boot splash
by Genes Lists 22 Dec '13

22 Dec '13

On 12/22/2013 03:22 AM, Thomas Bächler wrote: > Am 22.12.2013 03:11, schrieb Gerardo Exequiel Pozzi: >> Anyways, I am planning to replace gummiboot by syslinux in archiso. (but ... > Given the state of syslinux on EFI (fails to load some kernels entirely > for some people) and its lack of features (cannot chainload EFI > executables, for example), I am now very sceptical towards this. > > I've been installing arch on new systems the last couple of days - and am having great success with rEFInd - pretty straightforward and so far is working really well for me. gene

1 0

[arch-general] build and test packages automatically
by Guangyu Zhang 22 Dec '13

22 Dec '13

Hello, I want to build an repository. I need a software to build and test packages automatically, and to show the status of all packages which is just like the buildd <http://www.debian.org/devel/buildd/> in Debian. I have been looking for it via Google, but nothing found. Can anybody give me some advice? I also wonder what software is used by official developers to manage the main repository. Thanks, Guangyu

4 3

[arch-general] nut UPS driver (upsdrvctl) fails to start for usbhid devices due to node perms - howto fix?
by David C. Rankin 20 Dec '13

20 Dec '13

Guys, As a follow-on to the thread "package: network-ups-tools what happened to it?" I have discussed the fail-to-start issue with the nut developers and the reason why nut used to just "work" in the past for usb devices, but now no longer does without additional configuration. This apparently has to do with hotplug/udev permissions on newer Linux systems. I guess this went into Arch about 12-18 months ago, because that is when nut stopped working without further configuration. After working through errors starting the latest nut from git with systemd, the problem was that /dev/bus/usb/004/002 is owned by root:root forcing nut-driver.server to fail to start. Essentially upsdrvctl could not find/connect with /dev/bus/usb/004/002 and could not find the ups usb connection. Modifying the Execstart=/usr/bin/upsdrvctl start to: /usr/bin/upsdrvctl -u root start <upsname> allowed upsdrvctl to connect, but then created the state files in /var/state/ups with root:root permission which in turn caused nut-server.service (upsd) to fail on startup. upsd could not read the device files created in the state directory and could not create the upsd.pid as it was running gid "nut". Changing gid ownership of /dev/bus/usb/004/002 to root:nut solves all problem and allows upsdrvctl, upsd and upsmon to all start and connect fine. However, there is no way for the packager to know what bus a device with install or or whether it will be plugged back into the same port each time. I would like to investigate how Arch could be changed/configured so that nut simply runs out of the box as it used to before what ever changed changed. Is there a way the packager can do this? There are articles about rolling custom udev files -- that essentially accomplish linking the device to systemd and the ups name through /etc/ups/ups.conf: http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/ That too is something impossible for the packager to take into account when building the package. How do we package something like nut just works after it is installed like it used to? Essentially, what is broken is nut's ability to probe and connect to the ups device on startup due to the default device permissions. Did the usb devices used to have 0666 permissions in the past? That's the only way I can see upsdrvctl being able to probe/connect to the device right out of the box. What are the security consideration of having a usb device world writable? Could we modify the default Arch udev setup to recognize UPS devices and make these world writable by default? I don't know much about the new udev/usb logic, so I'm asking, what say the experts? -- David C. Rankin, J.D.,P.E.

4 6

[arch-general] Get netctl status from C?
by Daniel Bryan 17 Dec '13

17 Dec '13

I run dwm with a custom C program to update the status bar. So far I can check everything without needing to exec(), e.g. through libmpd, parsing /proc/meminfo, and so on. Is there a way to interface with the netctl profile system from C? I really just want to find the currently actively profile. I pulled down the code for netctl with abs and it seems to amount largely to shell scripts that will with stuff in /sys. It doesn't look too daunting, but I'd prefer a native interface if one exists. Thanks, Daniel

3 3

[arch-general] package: network-ups-tools what happened to it?
by David C. Rankin 14 Dec '13

14 Dec '13

Guys, Does anybody know what happened to the package "network-ups-tool" that provided UPS monitoring for CyberPower UPSs and others? I've search packages and I've searched AUR, but the only thing found was a very very old 'nutups' package in AUR that hasn't been updated in more than 2 years. I have an old PKGBUILD for network-ups-tools that I have updated to build on Arch, but it is pre systemd and still installs an init script. If network-ups-tools doesn't exists anymore, then what is a good link that describes how to correctly update the pkgbuild so it creates the needed /usr/lib/systemd/system/ entries and sets/loads the correct usbhid driver? If I have a good link/howto, I'll update it and put it in AUR. Thanks. -- David C. Rankin, J.D.,P.E.

2 3

[arch-general] ArchWiki: bad rendering on Android devices
by Jakub Klinkovský 11 Dec '13

11 Dec '13

Hi, I've noticed some pretty bad rendering of ArchWiki on my Nexus 7 - see the screenshots in [1]. The text seems to be indented from the right side (the width is approximately the same as the floating box for "Related articles", but the problem is not limited to pages with the floating box), while the boxed messages (notes, tips, warnings, code blocks...) are rendered correctly - well, almost correctly, sometimes even the text in boxes is indented (see the warning on one of the screenshots). At first I thought that it's just my browser, but then I saw the same behaviour on other devices, different browsers etc., so this is either bug in webkit or ArchWiki. Changing the user-agent string also does not help. Can more people confirm this? Is there something that can be done on ArchWiki? [1]: https://www.dropbox.com/sh/qxkdl3k7u97ljki/xvw-gFusBd -- Jakub Klinkovský (Lahwaacz)

3 4

[arch-general] r8168 network driver
by phanisvara 09 Dec '13

09 Dec '13

for the last year, or 1.5 years, i've been using r8168 from [community] because at that time r8169, which is included in the kernlel, didn't work properly. i got disconnected frequently, and often LAN speed dropped to ~0. after some kernel upgrades the r8168 driver needed to be re-built, and i kept filing bugs when this happened -- as now, after i got 3.12.4-1-ARCH. in the meantime i switched back to r8169 though, and lo and behold, it seems to be working fine now. i'm wondering if this may be the case for others as well? nothing changed in my hardware, but the kernel with the r8169 driver did, and now it's working fine for me. is r8168 still needed? -- phani.

1 0

[arch-general] The Final Cleanup
by Alexander Rødseth 06 Dec '13

06 Dec '13

Hi, This is the current situation: * Several packages in [community] (and maybe one package in [extra]) includes .desktop files * There is a 2 years, 8 months and 14 days old bug report, opened by Thomas Dziedzic, that opens with a few well chosen words, and is followed by a lengthy discussion: https://bugs.archlinux.org/task/23387 * For some packages, the lack of .desktop files has been reported upstream as bugs. * For some of those bug reports, upstream has: * Responded positively, and started to provide .desktop files (very few) * Responded that they will not provide .desktop files (even when provided in the bug report) * Not responded (seems to be the common case) * Several TUs and devs has had a go at moving things forward. The current effort is pretty spread out and has a long history: * Some are trying to keep the text in the bug report up to date. * Some are maintaining a wiki page about the topic: https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_files * Some are posting comments to the bug report. * A tool for generating .desktop files has been created, named "gendesk" (I'm guilty of this, and one or more of the above). * The bug has been closed and re-opened three times * We had an Arch Desktop Project going, that was started back in 2007, but is now obsolete: https://wiki.archlinux.org/index.php/Desktop_Project * Creating a TODO list has been suggested, some people are for this, others are against it. Here are the arguments so far for upstream being the ones providing the .desktop files: * It should not be the responsibility of the users * It should not be the responsibility of Arch Linux * It is increasingly common that upstream provides these * The real issue is that .desktop files should be provided by upstream Here are a few arguments against upstream being the ones providing the .desktop files: * Desktop shortcuts are not provided by upstream for other platforms, like Android, OS X or Windows (except when included in an installer) * Upstream should create the application, users should use it and packagers should make the application available to the user. This includes providing a .desktop file. * "Good luck trying to convince upstreams like dwm (and many others) to include them. IIRC the previous attempt didnt produce much either." Conclusion so far: Regardless of if it is correct that upstream should provide the .desktop files or not, the current plan is not working. TUs and devs are slow at reporting this as bugs and upstream are slow at responding. At the current rate, this will take years, perhaps decades. The current plan is not working. I think .desktop files should ideally be provided by upstream. But for cases where they are not currently being provided, we should provide them. Here are the arguments for removing .desktop files from packages (or not having them in the first place): * Arch Linux has vanilla packages, so we should try to avoid including files that are hand-crafted by packagers * It clutters the repository * Including .desktop files is basically the same as patching. And this quote: "Patching only occurs in extremely rare cases, to prevent severe breakage in the instance of version mismatches that may occur within a rolling release model." from https://wiki.archlinux.org/index.php/Arch_Linux * In all other connections, it is bad form to check in files to the repository that can otherwise easily be generated (like Makefile.am files, for instance) * Packages should be defined with as few text files as possible. Ideally just one PKGBUILD file. Here are the arguments for keeping .desktop files in packages: * If the existing ones are okay, there is no point in changing them * Upstream should fix them (this does not seem to be happening / this is happening at a rate that is too slow) I think .desktop files should not be kept in the packages, but either be provided by upstream or being generated by a tool. Here are the arguments for generating the .desktop files with a tool like "gendesk": * There is much duplication of code by having one .desktop file per (GUI) package * If the .desktop specification should change in the future, there is only one tool that has to be changed, not bazillions of little .desktop files * If there should be alternative ways of providing desktop shortcuts in the future, possibly for other desktop environments, the transition will be easier * It's more elegant than including manually crafted files everywhere * It provides one consistent look of .desktop files and avoids problems (for instance, one hand crafted (or upstream provided?) .desktop file used Terminal=1 instead of Terminal=true, which caused problems). Generated files are consistent, which avoids problems. * gendesk is already being used for several packages (and has been used for a while), and it seems to work fine * Many files are generating during the prepare or build process. .desktop files should be generated too. * "I've just tried gendesk and it's pretty neat actually." Here are the arguments against generating the .desktop files with a tool like "gendesk": * It is just like including base64 encoded files directly in the PKGBUILD. (no, it's not. Contrast with other build-time generated files) * It's better to just leave the current .desktop files as they are. * Generating the .desktop files does not make the packages more "vanilla". (.desktop files are inherently non-vanilla, though) * It takes a bit of work to create a package in the first place. Adding a .desktop file or not won't make a difference in the overall burden. * The functionality should rather be in makepkg. * The maintainer still needs to relate to .desktop files one way or the other I think .desktop files should be generated with "gendesk", or a similar tool. (Note that gendesk has evolved and improved quite a bit since the time when it was first introduced and commented on in the bug report). Here are the arguments for creating a TODO list: * It's time to get this done and close the age old bug report. * People can still choose to reserve their packages from being affected (simply by marking their packages as complete, for instance). * A TODO list is the appropriate method for solving this situation. * "I'm convinced TODO is more appropriate. Also I think the TODO interface (Complete/Incomplete) is better suited for this task." Here are the arguments against creating a TODO list: * Todos are things that require 100% completion ASAP for the distro to go forward I think we should have a TODO for this. Specifically, I think we should have a TODO for removing all .desktop files from our package sources. They should ideally be provided by upstream, but in the mean time, they should be generated. If there are no protests, I will, after some time (say, three days without any replies to this thread): * Create a TODO for this * Start fixing the packages (I will not fix the packages of maintainers that wish to reserve themselves from this, of course). We all appreciate a good discussion, but before replying with a flamey flame of a flaming reply, please think a minute if you have a better solution than this for achieving the goal of closing FS#23387 in the near future (not in 10 years). All the best. -- Sincerely, Alexander Rødseth xyproto / TU

2 1