- Arch-general - lists.archlinux.org

[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

[arch-general] Patch for update-mime-info slowness
by Sébastien Leblanc 06 Dec '13

06 Dec '13

I am kind of annoyed by the time it takes to update the MIME database (something like two minutes on a recent i7 quad-core laptop). Until pacman has hooks/triggers, I have removed the calls to fdatasync (which are supposed to ensure that the files are truly written to disk). I prefer letting the system take care of it anyway, and I don't care much for consistency in desktop links and file associations. Y'know, it might bear the name "database", but it's not a database in the sense of a +1M row postgresql database). Anyone have an opinion on this? Am I a complete idiot in removing these calls to fdatasync? With this patch, updating takes around 5 seconds, haven't run it with a stopwatch yet. -- Sébastien Leblanc

8 10

[arch-general] Virt-Manager Doesn't connect to localhost domain after upgrade.
by Peter Baldridge 06 Dec '13

06 Dec '13

Hello List, I've just recently upgraded with an Syu which included an upgrade from virt-manager 0.10.0-3 to 0.10.0.-4. This update seems to have pulled libvirt-python into the mix which from what I can tell was not there before or was not a separate package. (version 1.2.0-1-x86_64). My first attempt to update failed with the warning: error: failed to commit transaction (conflicting files) libvirt-python: /usr/lib/python2.7/site-packages/libvirt.pyc exists in filesystem I moved the file to my home directory and tried to install again. Update seamed to work but when I start virt-manager, I cannot connect to the localhost libvirtd and the daemon seems to be running fine: [/var/cache/pacman/pkg 2907 $ sudo systemctl status libvirtd libvirtd.service - Virtualization daemon Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled) Active: active (running) since Thu 2013-12-05 20:15:02 PST; 11s ago Main PID: 6466 (libvirtd) CGroup: /system.slice/libvirtd.service |-1194 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf `-6466 /usr/bin/libvirtd -p /var/run/libvirtd.pid Dec 05 20:15:03 zeke dnsmasq[1194]: reading /etc/resolv.conf Dec 05 20:15:03 zeke dnsmasq[1194]: using nameserver 192.168.1.1#53 Dec 05 20:15:03 zeke dnsmasq[1194]: using nameserver 8.8.4.4#53 Dec 05 20:15:03 zeke dnsmasq[1194]: using nameserver 8.8.8.8#53 Dec 05 20:15:03 zeke dnsmasq[1194]: using local addresses only for unqualified names Dec 05 20:15:03 zeke dnsmasq[1194]: read /etc/hosts - 2 addresses Dec 05 20:15:03 zeke dnsmasq[1194]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Dec 05 20:15:03 zeke dnsmasq-dhcp[1194]: read /var/lib/libvirt/dnsmasq/default.hostsfile Dec 05 20:15:03 zeke libvirtd[6466]: XML error: Storage pool config filename '/etc/libvirt/storage/pool.xml' does not match pool name 'default' Dec 05 20:15:03 zeke libvirtd[6466]: Could not find 'ebtables' executable Wenn I click to add a new vm, I get the error: Error: 'None Type' object has no attribute '__getitem__' and cannot proceed. I'm not sure where to go from here or where else to look. The Wiki briefly mentions the python api [1] and mentions that there should be some examples to look at though I don't see them on my system. Any pointers or google key words would be appreciated. [1]https://wiki.archlinux.org/index.php/Libvirt#Using_Python -- pete

2 1

[arch-general] New users not automatically added to 'users' group if -g default group specified?
by David C. Rankin 05 Dec '13

05 Dec '13

All, In the past with arch installs, new users have always been added to the 'users' group. Now that is not being done. If I recall correctly, I have always specified that users are members of a group with the same name as the user by manually creating the group and using the useradd -g <group> option. This was done to keep UID and GID numbers the same across multiple boxes. On older installs all users were made part of the users group: (July 2011 install) [08:31 nirvana:/etc/httpd/conf] # grep users /etc/group users:x:100:david,anna,blah,blah,blah (New install) [08:45 phoinix:/etc] # grep users /etc/group users:x:100: Is this expected behavior, or has something gone wrong with the install? I ask because https://wiki.archlinux.org/index.php/Cron#Users_and_autostart suggest that all users should already be members of the 'users' group. I don't mind manually adding the users, but if this is a bug, I'll report it. -- David C. Rankin, J.D.,P.E.

3 6

[arch-general] Fwd: Notebook freeze and slow when copy big files to external usb
by Maykel Franco 05 Dec '13

05 Dec '13

Hi, I when I make a copy of a large file to a 2GB or 8GB usb 3.0 external hard drive, I notice that arch remains slow, frozen ... He struggles to open windows are minimized. I have the kernel: 3.12.2-1-ARCH Update the whole system to the last. Can you think because it can be? I also went from the 3.11 kernel However, debian, ubuntu, opensuse me not pass this ... It's happened to someone else? Thanks for everything.

9 8

[arch-general] Fwd: Problem with kvm + virt-manager
by Maykel Franco 04 Dec '13

04 Dec '13

Hi, I'm spanish. I love archlinux. I used debian, opensuse, ubuntu, fedora, linux mint, fuduntu, gentoo and I like arch above all. I will install kvm in arch. I follow this guide: http://blog.desdelinux.net/instalar-y-configurar-qemu-kvm-en-arch-linux/ I have installed vmware workstation and virtualbox and works very well. But in kvm, when I create de VM I receveid this error: Imposible completar la instalación: 'Error interno: el proceso ha finalizado mientras se conectaba con el monitor: qemu-system-x86_64: -drive file=/home/maykel/archlinux-2013.10.01-dual.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /home/maykel/archlinux-2013.10.01-dual.iso: Permission denied ' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1920, in do_install guest.start_install(False, meter=meter) File "/usr/share/virt-manager/virtinst/Guest.py", line 1134, in start_install noboot) File "/usr/share/virt-manager/virtinst/Guest.py", line 1202, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib/python2.7/site-packages/libvirt.py", line 2897, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: Error interno: el proceso ha finalizado mientras se conectaba con el monitor: qemu-system-x86_64: -drive file=/home/maykel/archlinux-2013.10.01-dual.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw: could not open disk image /home/maykel/archlinux-2013.10.01-dual.iso: Permission denied I probed solution in google but not found... Can I help me please?? Is a bug of the virt-manager?? And now, I updated the system and I have bug in the virt-manager: maykel-arch /home/maykel :( # pacman -Q virt-manager virt-manager 0.10.0-4 https://bugs.archlinux.org/task/37990 Thanks in advanced.

2 1

Re: [arch-general] lz4 need add man doc
by Sébastien Luttringer 04 Dec '13

04 Dec '13

On 04/12/2013 06:53, Yi Zheng wrote: > Hi Luttringer, > > I checked the source pkg of lz4, and found that there is a man page > file named "lz4.1" available. But your PKGBUILD script do not install > it into the pkg. > > Do you think it is necessary add that doc? > Hi Zheng, Please use our bug report system[1] next time. [1] https://bugs.archlinux.org -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

1 0

[arch-general] dpms in text mode worked 1st boot, now monitor blanks but won't power off
by David C. Rankin 04 Dec '13

04 Dec '13

Guys, On my 1st boot after install of a new Arch box, the monitor would go to sleep in text mode. (monitor power light goes to yellow indicating sleep and screen goes black (off), not just blank) I thought that was a great trick, since normally, the screen just blanks, but the monitor doesn't really go to sleep (monitor power indicator on). Mouse movement (gpm) or key stroke would wake the monitor up as expected. After configuring the box (nothing related to display) on the next boot, the screen will blank, but not go to sleep (monitor power light remains on and screen goes blank, but not black (off)) I can't figure out what I could have done to alter anything related to the display. (configuration was to mysql, httpd, named, dhcpd, samba, etc....) What controls whether display powers off in text mode and what can I check for in journalctl to help figure this out? -- David C. Rankin, J.D.,P.E.

3 5

[arch-general] apache 2.4
by Caleb Cushing 04 Dec '13

04 Dec '13

I'm just curious as to why we're still on apache-2.2, at one point I think I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can think of at least one php application I tried to run which wouldn't work on it, so that's probably not it. -- Caleb Cushing http://xenoterracide.com Calendar: https://www.google.com/calendar/embed?src=xenoterracide%40gmail.com&ctz=Ame…

13 18