Re: [arch-general] Update delayed for more of two months, Lyx v2.1.4
Hi guys, Again the maintainer of Lyx [1] is so delay for update this package, here [2] is the pkgbuild updated and tested, can any TUs update this? Thanks [1]: https://www.archlinux.org/packages/extra/x86_64/lyx/ [2]: PKGBUILD[1] -- Xavier Corredor Llano On Saturday, 24 October 2015 11:19:54 COT Antonio Rojas wrote: > Xavier Corredor Llano wrote: > > Hi guys, > > > > After more than two months ago Lyx [1] released the version 2.1.4 [2], > > this is a minor and maintenance release (strongly recommended), in august, > > and after flagged as out-date and wait some days, I contacted with the > > maintainer (Ronald) and he didn't answer me (I understand, maybe he is > > busy) > > > > I tested for more of two months and this release work fine, I would like > > to be the maintainer of this package but I am not TU. > > > > Regards > > > > [1] https://www.archlinux.org/packages/extra/x86_64/lyx/ > > [2] http://www.lyx.org/News > > Updated [1] https://drive.google.com/file/d/0B2KQf7Dbx7DUM2MtaXBxb3kzY0k/view?usp=drivesdk
[arch-general] Update delayed for more of two months, Lyx v2.1.4
Hi guys, After more than two months ago Lyx [1] released the version 2.1.4 [2], this is a minor and maintenance release (strongly recommended), in august, and after flagged as out-date and wait some days, I contacted with the maintainer (Ronald) and he didn't answer me (I understand, maybe he is busy) I tested for more of two months and this release work fine, I would like to be the maintainer of this package but I am not TU. Regards [1] https://www.archlinux.org/packages/extra/x86_64/lyx/ [2] http://www.lyx.org/News -- Xavier Corredor Llano -- Forwarded Message -- Subject: Lyx 2.1.4 Date: Saturday, August 15, 2015, 07:11:42 PM From: Xavier Corredor Llano <xavier.corredor.ll...@gmail.com> To: ron...@archlinux.org Hi Ronald! I have tested the Lyx [1] version 2.1.4 with the PKGBUILD attachment and work fine. Regards [1] https://www.archlinux.org/packages/extra/x86_64/lyx/ -- Xavier Corredor Llano -
[arch-general] aur xfce4-dev
Hello, Due to a lack of time, I'll orphan all the xfce4-dev aur packages this evening. If someone is interested in adopting them. Tcho
Re: [arch-general] Recently orphaned [community] packages, TUs should take a look if they might be interested in adopting them.
Hello, If no TU interested in celt, I'm interested to maintain it in AUR. On 09/26/2011 11:19 PM, Thomas Dziedzic wrote: Hi, I recently went over all my packages in community, and have decided to orphan the following due to lack of interest and because I haven't used them in a long time celt - Low-latency audio communication codec extrema - Extrema is a powerful visualization and data analysis tool. ghdl - A complete VHDL simulator, using GCC technology. gnofract4d - A fractal browser with PyGTK gui grass - Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modeling, and visualization. gtkwave - A wave viewer which reads LXT, LXT2, VZT, GHW and VCD/EVCD files gts - GNU Triangulated Surface Library. luakit - luakit is a highly configurable, micro-browser framework based on the WebKit web content engine and the GTK+ toolkit.Stable release mpdscribble - An mpd client which submits track info to last.fm netbeans - Netbeans IDE development platform. protege - Free, open source ontology editor and knowledge-base framework wordpress - Blog Tool and Publishing Platform All of them are working as far as I know, and they have no outstanding bugs except a couple which are in the list of pushing the .desktop file upstream https://bugs.archlinux.org/task/23387 (already reported) and luakit has an extremely minor upstream bug https://bugs.archlinux.org/task/25761 which is also reported. Cheers!
Re: [arch-general] Xfce 4.8 thunar/ristretto issues
Hey, You have to start tumbler for your thumbnails (/usr/lib/tumbler-1/tumblerd). Concerning ristretto, if you click on one image it only opens the image and not the entire folder. You can also change this behavior in the preferences and select Open entire folder on startup. BRs, On 01/18/2011 04:43 PM, Ricky Thomson wrote: Hello Having 2 minor problems with xfce since the update to 4.8. First problem is that no thumbnails are being cached/displayed by thunar anymore. I have tried deleting ~/.thumbnails and all xfce related config files in ~/. Previously i had installed the xfce4-goodies package so i believe the thumbnailers scripts/programs are on my system. How to fix this? Second problem, when opening ristretto (xfce image viewer) for example several images in one folder, the arrow buttons to display the next image in the folder are unclickable/unresponsive. Gets kind of awkward trying to view several images quickly. As i said i have tried deleting config files under ~/ which might be broken from the upgrade. So i'm not too sure what to do. Packages in question: -- thunar 1.2.0-1 ristretto 0.0.91-1 Thanks in advance.
Re: [arch-general] lcms - needs upgrade because of security
On Sat, Aug 14, 2010 at 9:54 PM, Kurt J. Bosch kjb-temp-2...@alpenjodel.de wrote: Am 2010-08-14 21:48, schrieb Laurent Carlier: You should fill a bugreport as there is security issues No. Last time I did this it was rejected - http://bugs.archlinux.org/task/10679 That reject was plain wrong, we should encourage users to give visibility to security updates. However that was 2 years ago, so please let me know if this happens again.
Re: [arch-general] nfs problem
And what if you allow ALL access to the server for the client and to the client for the server ? On 07/17/2010 04:57 PM, Lars Tennstedt wrote: Hello, I tried to set up a nfs server and a nfs client in my network. I followed the instructions from the arch linux wiki. The server's ip address is 192.168.0.100 and the client's one is 192.168.0.101. I inserted the option --no-notify in /etc/conf.d/nfs-common.conf on the server. Here are the entries of the configuration files. --- On the server --- /etc/export: /home/user/share 192.168.0.101(rw,sync,no_root_squash,no_subtree_check) /etc/hosts.allow: nfsd: 192.168.0.101/255.255.255.255 rpcbind: 192.168.0.101/255.255.255.255 mountd: 192.168.0.101/255.255.255.255 --- On the client --- /etc/hosts.allow: rpcbind: 192.168.0.100/255.255.255.255 If I try to mount the nfs share with the command mount 192.168.0.100:/home/user/share /home/user/share, I will get the error message mount.nfs: access denied by server while mounting. The directories /home/user/share on both machines are owned by the user. Maybe someone has an idea? Thanks! Bye Lars
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Sun, Jun 13, 2010 at 11:38 AM, Ananda Samaddar ana...@samaddar.co.uk wrote: This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates? It's all there : http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg and there : http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman Come back to us when everything is implemented and working :) You can also read the last thread : http://mailman.archlinux.org/pipermail/arch-general/2010-April/012897.html And contact Denis A. Altoé Falqueto about pacman-key and all the rest, and maybe Aleksis Jauntēvs too Basically there is no one leading and coordinating these efforts, just various people who pushed it a bit at random time in the past, and got quickly de-motivated by the lack of interest from everyone else.
Re: [arch-general] [arch-dev-public] [PATCH] Check all checksum types
On Tue, Jun 8, 2010 at 1:00 PM, Kazuo Teramoto kaz@gmail.com wrote: On Tue, Jun 8, 2010 at 2:33 AM, Allan McRae al...@archlinux.org wrote: Check every checksum that makepkg supports rather than only md5sums. Fixes FS#17168. Signed-off-by: Allan McRae al...@archlinux.org --- I am sure there has to be some way to loop through all that duplication, but the how escapes me... getattr? What about the attached implementation of checksums.py? Note: I dont tested it! Did you attach anything ?
Re: [arch-general] Cannot install shaman from AUR
On Sat, Jun 5, 2010 at 7:36 AM, xenof0nt xenof...@gmail.com wrote: Sorry there is no other alternative. The only solution is Shaman2 but currently is in Alpha stage. That means it is highly unstable and dangerous for your system. Arch will never provide a graphical tool for pacman. So if you can't live with this, then change to another distro Never say never. Just curious, where does that come from ? Why couldn't a sufficiently motivated developer write a GUI frontend to libalpm good enough to get it packaged ? This actually happened with shaman, it was packaged in community by the main makepkg developer, Allan !
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
On Wed, May 26, 2010 at 4:31 PM, Xavier Chantry chantry.xav...@gmail.com wrote: Then, if you want to do something about it, just go ahead and talk with these people Joerg kindly mentioned. Ask them whether they agree or disagree with Eben's interpretation that GPL compliance on mkisofs is broken : http://mailman.archlinux.org/pipermail/arch-general/2010-February/010989.html Dozens of people have contributed to the discussion, but no one actually cares about getting some clarifications ? I just don't get it. I feel like I did my part of the work already by getting a report from Eben, just to see Joerg accusing him of lying in return. Now it would be very nice and useful if someone could continue that work by getting in touch with other competent people.
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
On Thu, May 27, 2010 at 5:52 PM, Loui Chang louipc@gmail.com wrote: On Thu 27 May 2010 14:43 +0200, Xavier Chantry wrote: Dozens of people have contributed to the discussion, but no one actually cares about getting some clarifications ? I just don't get it. I feel like I did my part of the work already by getting a report from Eben, just to see Joerg accusing him of lying in return. Now it would be very nice and useful if someone could continue that work by getting in touch with other competent people. That would be nice and useful if people actually believed that there would be an end to this discussion. Anyways, it's been stated that licensing isn't really the issue any more. The fact is no Dev or TU is interested in maintaining cdrtools. Jörg has something to learn a how to deal with people, but he's too stubborn to take any advice. The licensing doubt might not be a show-stopper for Arch, but clearing it would still increase the chances of a dev/tu packaging it. And I was not just thinking about Arch, I was thinking about every potential packagers/distributors of cdrtools, this would be useful for all of them. So if anyone wants to become the first useful person in that discussion, (s)he knows what to do. And as a sidenote, one TU showed interest the first time : http://mailman.archlinux.org/pipermail/arch-general/2010-January/010358.html I suppose he got scared away by the endless discussion.
Re: [arch-general] regression in nouveau ?
On Wed, May 26, 2010 at 2:08 AM, Philipp Überbacher hollun...@lavabit.com wrote: Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all. It's definitely not their primary focus. But if you open a bug report saying that commit greatly increased latency and you can prove it, you can be sure they will do something about it. The work to provide good, detailed, and useful bug reports is in user's hands, not developers'. When the users don't do their homework, regressions remain.
Re: [arch-general] regression in nouveau ?
On Mon, May 24, 2010 at 11:42 PM, Xavier Chantry chantry.xav...@gmail.com wrote: Also note the first item about latency on this page : http://nouveau.freedesktop.org/wiki/ToDo Ah now I remember where this latency TODO came from, there actually was one report about bad latency earlier that month (february) : You could read the following thread : http://lists.freedesktop.org/archives/nouveau/2010-February/004960.html There were several tips about modifying xorg driver to improve things and get more debug information. Did you also switch from UMS - KMS between 2.6.32 and 2.6.33 ? It's easy to tell, it brings you native (high) resolution in tty / consoles. Maybe the problem always existed in the KMS path, and it's the only way now.
Re: [arch-general] Burning From Command Line
On Wed, May 26, 2010 at 8:32 PM, C Anthony Risinger anth...@extof.me wrote: at the possibility of playing devils advocate, i don't see anything outrageous by Jeorg's claims... even after reading the full 40+ messages twice and the yay thread started afterwards. Sorry to inform you that you did not read enough. seriously, nobody is going to sue us for using the cdrtools package... who? the guy that more or less owns it and is trying to get us to use it? doubtful. this seems like a bunch of political/personal nonsense, with a fair amount of personal jabs and condescending attitudes toward Jeorg. mind, i am entering this conflict without prior knowledge or bias. i did not even know there was a difference between wodim and cdrtools/cdrecord... as Jeorg pointed out this is a _problem_. his software's reputation is most assuredly suffering from this misinformation. If you think I had any bias towards Joerg before reading this mailing list, well, you are wrong. Any judgments I might have is based on what he posted here. I don't see why other people should be biased either, Arch ML was spammed well enough on this topic that any reader can make his own opinion. if Arch was truly worries about legal issues (which seems to be a complete moot point from my experience here), surely this package: http://www.archlinux.org/packages/extra/i686/libdvdcss/ would not even be REMOTELY close to an OFFICIAL repo! am i right? i don't know ANY other distro that includes it. in the spirit of open licenses, mildly incompatible or not, include the best tool for the job = cdrtools. It's not the only issue. What we need is a Arch developer that is : 1) willing to package cdrtools despite the license doubts 2) willing to work with Joerg as upstream (see http://mailman.archlinux.org/pipermail/arch-general/2010-May/013557.html) That possibility was never completely excluded. But by endlessly trolling on our Mailing List and not showing much co-operation, Joerg is making more enemies than friends among Arch community and developers. IMO he would do himself a big favor by staying quiet. Since his software is technically superior, and is not completely unknown, people should recognize that and start using it by themselves. If a Arch user reports recording troubles with wodim, it's likely that another Arch user will recommend him to try out cdrecord, which is documented in Arch wiki and available in AUR. The good reputation of the software is built by the community, not the words of wisdom of the software's author. on a final note, Jeorg, it would be extremely beneficial if you could cite a hard resource regarding the legalities involved here, as you seem to have a resource. or maybe just dual license cdrtools (why not?). why was the license changed to CDDL exclusive anyways? i've been in lengthy license discussion over on Phoronix, and i must admit, the more i get into software as a living [6+ yrs now], the less i like the GPLv* (notice nobody moves TO the GPL, they only move AWAY... this, CouchDB [apache], etc... GPL is too purist IMO) 20 people asked this before you on this very same mailing list. Why do you think you are so special that he would listen to you ? And if you had read this : http://mailman.archlinux.org/pipermail/arch-general/2010-February/010989.html You would know there is not even a need for a dual license or a license change, just a simple clause : After speaking to Jörg we began our review of the complete source of cdrtools, and soon verified that GPL compliance on mkisofs was broken. We told Jörg that as far as we could see he was the only copyright holder on the CDDL'd libraries, which he confirmed. In that case, I pointed out, he could give all the permission necessary to solve the problem, without any license changes: he simply needed to give permission as the relevant copyright holder on the CDDL's libraries for combination with mkisofs and distribution of the binary and source under the terms of GPL, without any additional restrictions. We drafted for him the thirty-nine words needed: You are permitted to link or otherwise combine this library with the program mkisofs, which is licensed under the GNU General Public License (GPL). If You do, you may distribute the combined work under the terms of the GPL.
Re: [arch-general] regression in nouveau ?
On Wed, May 26, 2010 at 10:46 AM, f...@kokkinizita.net wrote: Looking at the xrun statistics in function of audio period size, it looks like current nouveau is blocking audio (either by dis- abling interrupts, or by locking a shared HW resource) for about 3-4 ms. *No* driver today should ever do that - it's really late 1990's performance. As I said, there are some people who are willing to help in that area. But without people like you reporting and testing, it's never going to happen. We need audio guys and graphics/drivers guys allocating some times to work together and resolve the issues. There was at least one nouveau developer trying to help out : http://lists.freedesktop.org/archives/nouveau/2010-February/004981.html But the reporter just disappeared. I just talked to him on IRC #nouveau, here are some extracts : 23:01 stillunknown you need someone with the time and the itch to pursue this 23:02 stillunknown because the magic solution isn't going to drop from the sky 23:02 stillunknown we can help, but that goes for anyone 23:07 stillunknown shining: my first guess is that we disable irq's in a few code paths 23:14 stillunknown my guess is the irq disabling around fences, since that is the only thing that i suspect will trigger frequently when rendering 23:16 stillunknown makes me wonder why we disable irq's there 23:16 stillunknown mailinglist time :-) 23:18 stillunknown ah for nv04 i can understand, but for the rest not so much If there is no one to test / experiment, I am afraid the situation won't improve anytime soon. And just a reminder that these people help/work for free in their limited spare time :)
Re: [arch-general] regression in nouveau ?
On Wed, May 26, 2010 at 12:32 AM, f...@kokkinizita.net wrote: I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS. I don't know what you are saying. Just use nvidia. or nv or vesafb. Or if none of the drivers suits you, just use a different brand. Or if none of linux graphic drivers suits you, then use a different os.
Re: [arch-general] Burning From Command Line
On Sun, May 23, 2010 at 12:41 PM, Rasmus Steinke r...@xssn.at wrote: Jörg has a point. While of course being biased about his pet cdrtools, cdrkit is not on par with cdrtools in any way. Those updates you mention more or less only consist of small fixes, no progess at all in that package. The ONLY reason cdrkit is used in many distributions is the license of cdrtools. Jörg mentions on his website that suns lawyers have analyzed the legal issues. Unfortunately there is no link to that analysis which makes this a pure claim. Jorg also mentioned that Eben Moglen approved the original software : http://mailman.archlinux.org/pipermail/arch-general/2010-January/010380.html which was proved to be wrong from Eben Moglen himself : http://mailman.archlinux.org/pipermail/arch-general/2010-February/010989.html This doesnt change the fact that cdrtools is clearly superior to cdrkit. (Just check arch's bugtracker) Rasi If this wasn't the case, the situation wouldn't suck as much. Everyone would just use cdrkit without second thoughts. But when a project is forked by external (non-involved) people simply for fixing the license rather than fixing real technical problems, I wouldn't expect great progress being made. Anyway let's stop talking about all this non-sense BS. I am very happy with how the wiki (http://wiki.archlinux.org/index.php/CD_Burning) presents things by staying very practical. Install packaged cdrkit, and if it doesn't work for you, install cdrtools from AUR.
Re: [arch-general] regression in nouveau ?
On Mon, May 24, 2010 at 11:00 PM, f...@kokkinizita.net wrote: Hello all, over the past few months I have installed Arch on a number of systems, all of them used for quite intensive audio work (think of systems with 1000 jack ports). All of them have worked flawlessly, no latency problems even with the standard kernel. Today I installed one more, on exactly the same HW as the previous one which was something like 6 weeks ago. Main difference is probably kernel 2.6.33 instead of 32. This system is completely unusable: almost anything 'graphical' - opening or closing windows, changing workspaces, etc. will generate showers of xruns. Using nouveau's 'no_accel' option solves the xruns, audio is as stable as it has ever been. But the system is again useless - just scrolling an xterm up one line takes a second or so. Nor has using this option been necessary before (all of the previous installs use nouveau). So has anything changed in nouveau that can explain this ? Any solutions ? Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ? If you still have the same problems with git, you should ask upstream (irc freenode #nouveau or ML http://lists.freedesktop.org/mailman/listinfo/nouveau) http://nouveau.freedesktop.org/wiki/FrontPage But it would help to have as much precision as possible about what is the latest version of each nouveau component that worked, and what is the first that is bad, i.e. minimizing the regression window. Also note the first item about latency on this page : http://nouveau.freedesktop.org/wiki/ToDo
Re: [arch-general] Burning From Command Line
2010/5/23 Ng Oon-Ee ngoo...@gmail.com: On Sat, 2010-05-22 at 23:07 -0400, Daenyth Blank wrote: On Sat, May 22, 2010 at 22:49, Nilesh Govindarajan li...@itech7.com wrote: What ? Is that really true ?!?!? State some link where it is officially declared by the developers. Joerg is the author of the software he recommends, so not exactly unbiased... Well, on the flip-side he wrote the software, so his word can be considered the 'official declaration'. This was discussed on this ML a couple of months back, just search Joerg's name as he was (obviously) one of the main contributors to that conversation. Well.. the official declaration for cdrecord, not for wodim. If you want to hear the wodim side, it happens there : http://www.cdrkit.org/
Re: [arch-general] AIF through proxy
On Sat, May 22, 2010 at 11:38 AM, Dieter Plaetinck die...@plaetinck.be wrote: On Sat, 22 May 2010 02:04:41 +0200 Andre \Osku\ Schmidt andre.osku.schm...@googlemail.com wrote: On Fri, May 21, 2010 at 10:56 PM, Dieter Plaetinck die...@plaetinck.be wrote: On Fri, 21 May 2010 22:41:12 +0200 Andre \Osku\ Schmidt andre.osku.schm...@googlemail.com wrote: just gives me the usage info, without any errors... and also the Invalid URL scheme errors that i see in tty7 are nowhere to find in /var/log/* what i would do in a case like this is just monitor the output of 'pstree' to see which processes is running (ie wget, pacman, ..), then you can debug the networking issue from there. oooh! you learn new things every day :) super tip. thanks! i got something, maybe pstree shows (when it hangs in url scheme error) aif /sbin/aif -p automatic -c /root/pacinst.aif -d -l |--pacman --root /mnt --config /tmp/pacman.conf -Sy and as according to some forum post (and it seems to work only with this) i had to uncomment: XferCommand = /usr/bin/wget ... in /etc/pacman.conf to get pacman to work on the installer image console. and now looking at the /tmp/pacman.conf, this option is missing. but as i assumed (and test showed) the /tmp/pacman.conf gets newly generated on every aif run. so i cant edit that. what file could i edit to get that xfercommand in /tmp/pacman.conf (this looks even closer, OMG! /me is crossing fingers... :) another tip: just grep in the aif source code and you'll see. if you grep for '/tmp/pacman.conf' you'll see there is a function target_write_pacman_conf in lib-pacman.sh, like any other function you can override this with your own. awesome tip! many thanks, again! at line 72 in /usr/lib/aif/core/libs/lib-pacman.sh i added: XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u and aif gets packets though squid! and whats even better, pacproxy.py works too, YAY! going to bed tired and happy :) .andre actually i meant you can redefine the target_write_pacman_conf in your profile (pacinst.aif) btw i checked pacman.conf and it seems pacman by default uses a built-in http thingie, which does not support proxies. I think for aif, it's probably better to use the wget Xfercommand so that proxies work, especially for the target system. i'll check this on the pacman-dev mailing list. (btw you forgot reply to all) Dieter libfetch does support many proxy just fine, but it might be less flexible than others. Andre, can you show us *exactly* how you set http_proxy variable ? In particular make sure you specified a protocol for the the URL.
Re: [arch-general] Fwd: AIF through proxy
On Sat, May 22, 2010 at 7:19 PM, Dieter Plaetinck die...@plaetinck.be wrote: or write this to /etc/profile: alias pacman='http_proxy=.. ftp_proxy=.. pacman' I would suggest that last way, either an alias or shell function or shell wrapper.
Re: [arch-general] [arch-dev-public] phoronix: Is Arch faster than Ubuntu?
On Wed, May 19, 2010 at 7:18 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Wed, May 19, 2010 at 12:07 PM, Dan McGee dpmc...@gmail.com wrote: On Wed, May 19, 2010 at 12:02 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: Came across my reader today http://www.phoronix.com/scan.php?page=articleitem=ubuntu_arch_fasternum=1 Pretty neat. Showing boot-up time and other more noticeable waits would be a much better comparison; I think the benchmarks are not why people think Arch feels faster. Right but the reason I think this is interesting is that the data shows it is feels faster not is faster. I basically agree with everything that was said and will try to re-conciliate the different opinions : 1. This benchmark is not particularly useful, as we are often used with Phoronix. They are often not well chosen and/or with bad interpretation, so it often annoys people who know better about a specific software/project. 2. Phoronix's benchmarks have the merit to exist and to provide facts, as opposed to many users who claims X is faster than Y, and NEVER provide any facts/numbers/benchmarks, even when specifically asked. I saw it happening many times in Arch community over the time, so now we at least have some data to show them. So I would still thank phoronix for providing benchmarking tools and results, which are definitely useful and needed. IMO the most interesting benchmarks are the ones comparing different versions of the same software, but this would also better be made in collaboration with upstream developers, as these are probably the only people able to really make sense and explain results. In any cases, thanks for the link Aaron :)
Re: [arch-general] vim runtime woes
On Fri, May 14, 2010 at 1:07 AM, Jan Steffens jan.steff...@gmail.com wrote: The vim runtime that can be retrieved via rsync is outdated. Some of the patches modify the runtime, and some of these changes (e.g. 394) are lost when the runtime is overwritten with the runtime from rsync. Not using the runtime from rsync at all also misses some updates. Any thoughts on how to solve this? One option would be to build vim from Mercurial (http://vim.googlecode.com). Just in case people think this is a theoretical problem no one cares about ... solving this would give us tar.xz support that comes with latest version of gzip plugin : http://code.google.com/p/vim/source/browse/runtime/plugin/gzip.vim Never opened a package in vim ? it's awesome :p Anyway, this is just an example, we are also missing the latest greatest changes in many runtime files. Well not me, as I use vim-hg, and I would recommend other vim users to do the same. http://aur.archlinux.org/packages.php?ID=33422
Re: [arch-general] PKGBUILD parser
On Mon, May 10, 2010 at 1:23 AM, Allan McRae al...@archlinux.org wrote:
On 10/05/10 02:06, Loui Chang wrote:
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
On Sun, May 9, 2010 at 2:44 PM, Allan McRaeal...@archlinux.org wrote:
Sourcing is dangerous if the PKGBUILD is from an untrusted source. It
also
fails with package splitting...
But I just had an idea now, if we're thinking about AUR use case :
makepkg --source could generate a suitable and parsable file providing
all information that AUR needs, and ships that next to the PKGBUILD in
the source tarball. Does that sound crazy ?
This would not fix the problem now, but it could fix it eventually,
when most pkgbuilds are re-submitted. Or this parsable file could be
generated for all pkgbuilds in a row, just for the conversion, in a
chroot/jail on a machine not in production.
Yeah I've thought about this as well. Source packages could have a
similar format as binary packages with a .PKGINFO file to present the
metadata in an easily parsable format.
You can read some of my incomplete brainstormings here:
http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz
I am told I like to be really negative anytime this is bought up... it is
not deliberate, I just see the barriers to this working. So here we go! I
know you have pointed out some problems already and this is related.
makepkg does not actually parse any of the splitpkg overrides until build
time. How do we get the packaging variable overrides without actually making
the package (and on every architecture)? We would need to extract the
needed fields from the package functions somehow. So that brings us back to
needing to hack a bash parser in makepkg or to actually require the package
building to take place before you can create a source package. And this is
not restricted to package splitting...
e.g.
pkgname=foo
...
# depends not needed at make time
# depends=('bar')
...
package() {
depends=('bar')
}
Welcome to the world of makepkg hacks... And do not think such hacks are
not used. The old klibc PKGBUILD generated a provides array in the build
function on the basis of a file name only available at the end of the build
process.
The joy of PKGBUILDs is that they are so flexible. The problem with
PKGBUILDs is that they are so flexible.
The biggest problem indeed comes from any variables that are declared
inside a function. Well, it's easy, let's just make a rule to forbid
it.
Any AUR packager who breaks the rule will have its package data messed
up in the AUR interface. Too bad for him/her.
The klibc package is/was an exception, not the rule, and it wasn't on
AUR so less problematic (still problematic for other tools like my
python check-packages for integrity check, but well).
So the main thing is split variables that need to be moved top-level.
Dan, Aaron and I had some proposals / examples how to deal with that.
You were included in the few mail exchanges we had but I am not sure
if you did receive all of them as you didn't reply directly in that
thread, I will forward it to you.
Re: [arch-general] PKGBUILD parser
On Sun, May 9, 2010 at 2:44 PM, Allan McRae al...@archlinux.org wrote: Sourcing is dangerous if the PKGBUILD is from an untrusted source. It also fails with package splitting... Makes me wonder why pkgbuilds are written in bash. Sounds like a big design flaw. But it depends on what our needs are : 1) we don't care about untrusted source or security, we always trust the source, then bash sourcing is very convenient (original idea behind that design) 2) we care about security and dealing with untrusted source in a secure way : the existing format sucks Currently we are neither in 1), nor in 2), we are somewhere in the middle with the inconvenient of both sides. We lost the convenience of 1) bash sourcing with package splitting. (I've been meaning to fix this for one year or so, just never got to it). And we don't have any ideas about how we could ever suit 2). Changing pkgbuild format doesn't sound really doable and realistic, it might be the most important characterization of what Arch is, changing it would make a new distrib. But I just had an idea now, if we're thinking about AUR use case : makepkg --source could generate a suitable and parsable file providing all information that AUR needs, and ships that next to the PKGBUILD in the source tarball. Does that sound crazy ? This would not fix the problem now, but it could fix it eventually, when most pkgbuilds are re-submitted. Or this parsable file could be generated for all pkgbuilds in a row, just for the conversion, in a chroot/jail on a machine not in production. To re-iterate : PKGBUILD format was meant to be easy to parse by using bash source. The moment you stop using bash source, it's just all wrong, and it's the format you have to change.
Re: [arch-general] PKGBUILD parser
On Sun, May 9, 2010 at 6:06 PM, Loui Chang louipc@gmail.com wrote: Yeah I've thought about this as well. Source packages could have a similar format as binary packages with a .PKGINFO file to present the metadata in an easily parsable format. You can read some of my incomplete brainstormings here: http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz Ah, that's great, never heard of that before ! A few comments : - using the PKGINFO format sounds like a good idea, but not sure why you want to keep the same name. As you noticed yourself, this would cause stupid problems like a possible confusion between source and package tarballs. Better just call it SRCINFO, so pacman will never be confused. - for split pkgbuilds and arch , well... Maybe it would be simpler to write as many SRCINFO as there are PKGINFO/packages , i.e. one for every combination of split name / arch. Maybe all these files could be all combined into just one, I am not sure. But I would not care about data duplication, I would rather keep it as dummy and easy to parse as possible.
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On Fri, May 7, 2010 at 10:43 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, I have had vim and gvim installed side by side for 6 months+, today during update, pacman wanted to remove vim because it now conflicts with gvim. So I removed gvim and updated. What is the conflict? Why a conflict now when there hasn't been one in the past? Just checking... Maybe try irc next time, at least people won't debate for hours whether you should have searched first or not. They will just tell you to read the f* news, possibly with a link :)
Re: [arch-general] [arch-dev-public] [toolchain] gcc 4.5 breakage
On Thu, May 6, 2010 at 3:25 PM, Rogutės Sparnuotos rogu...@googlemail.com wrote: All this is probably unrelated to http://gcc.gnu.org/PR43987, but perhaps it will save some time for someone, as your post about busybox helped me. I'll wait for a new gcc package before reporting a gcc bug. IMO you should report it now, especially considering that the current package is a stable gcc release.
Re: [arch-general] Crisp Rendering Fonts
On Thu, Apr 29, 2010 at 7:37 PM, Michishige Kaito chris.webs...@gmail.com wrote: Anti-aliasing is turned off for small point sizes and turned on for larger sizes. Denis. I'd be very interested in finding out how this is controlled. Could you point me at a resource on the topic? http://wiki.archlinux.org/index.php/Font_Configuration#Enable_anti-aliasing_only_for_bigger_fonts
Re: [arch-general] How to take screenshot of ring switcher ?
On Thu, Apr 29, 2010 at 8:03 PM, Nilesh Govindarajan li...@itech7.com wrote: I know this is a silly reason, but this is the general trend I've observed dealing with people in real life and on the internet. They fear from using Linux because they think it has no GUI or it is bad. Well that's not completely wrong. Tell me how many people install/use/maintain an Arch system without ever touching the command line ? The kde+qt vs gnome+gtk separation doesn't help either for having a coherent and consistent GUI experience. Even Ubuntu documentation contains some occasional commands lines, e.g. random example : https://help.ubuntu.com/9.10/keeping-safe/C/firewall.html#id2774297 A lot of ubuntu guide/tutorial often relies on the command line as well. However all the big distrib have indeed made a lot of effort to provide more and more GUI for every aspect of the system, and it improved a lot in the last years. I don't know if a stupid compiz effect is a good illustration of that progress, but well. Anyway while it's true you can do a lot via a GUI on ubuntu,fedora,suse,etc nowadays, what would Linux be without its great and powerful CLI ? I spend a lot of times every day using a linux terminal, and I just love it. I miss it a lot every time I am forced to use windows.
Re: [arch-general] [arch-dev-public] [signoff] gcc-4.5 toolchain rebuild
On Sat, Apr 17, 2010 at 3:48 AM, Emmanuel Benisty benist...@gmail.com wrote: Thanks for your reply Allan. On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae al...@archlinux.org wrote: On 17/04/10 00:03, Emmanuel Benisty wrote: Just out of curiosity, what is the plan regarding this issue (quoted from the gcc changelog): On x86 targets, code containing floating-point calculations may run significantly slower when compiled with GCC 4.5 in strict C99 conformance mode than they did with earlier GCC versions. This is due to stricter standard conformance of the compiler and can be avoided by using the option -fexcess-precision=fast; From what I understand, this requires passing -std=c99 (or equivalent) to the compiler for it to use strict C99 mode. So most software will not be affected. Of course, the maintainer of any software the does set C99 mode should consider this. If it does affect only that type of code and if you recommend the maintainers to use this option in those cases then wouldn't it simpler to add it to /etc/makepkg.conf by default and thus make it a no-brainer for maintainers? What's wrong with stricter standard conformance ? That sounds like a good change. How can you tell that these apps with floating-point calculations were not actually buggy with previous versions of gcc (or with -fexcess-precision=fast now) ? It does not seem a very good idea to set that globally. I think that should be done case per case, and not by maintainers, but by the developers of the apps, who know well their code, and can make a reasonable decision whether they want/need performance or conformance/accuracy. And you *need* to know how these two aspects are affected if you want to make a reasoned and informed change, rather than a blind and clueless one.
Re: [arch-general] keyboard not working in Xorg after package updates
On Fri, Apr 9, 2010 at 5:05 AM, David Rosenstrauch dar...@darose.net wrote: On Thu, April 8, 2010 9:51 pm, David Rosenstrauch wrote: So WTF?!?!?!? Hal sees the keyboard. And xev running inside the x session sees the keyboard. SO WHY ON EARTH IS MY KEYBOARD STILL DEAD IN MY X SESSIONS?!?!? AHH Wee hee! It gets weirder! * Bizarrely enough, *some* of the keys on the keyboard actually work (such as / * - + on the numeric keypad). * I'm getting a load of errors in the slim.log file that look like this: expected keysym, got XF86_Switch_VT_1 line 8 of xfree86 W T F ? ! ? Did you try googling for that error ? For instance I felt on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364932 which gives many things to check.
Re: [arch-general] keyboard not working in Xorg after package updates
On Fri, Apr 9, 2010 at 3:54 PM, bardo ilba...@gmail.com wrote: 2010/4/9 David Rosenstrauch dar...@darose.net: * I'm getting a load of errors in the slim.log file that look like this: expected keysym, got XF86_Switch_VT_1 line 8 of xfree86 W T F ? ! ? Not sure it's the same problem, but I experienced something similar a while ago... and I couldn't properly use my desktop for months =P Did you install NX or similar lately? Check this one out: http://bugs.archlinux.org/task/15236 And by the way, one of the last comments in the debian bug is the following : Thank you for your advice. In fact the bogus files were in /opt/lib/NX/lib. So it was an old (1 year ago) and bad installation (from an archive) of NoMachine libraries which mess up my system.
Re: [arch-general] keyboard not working in Xorg after package updates
On Wed, Apr 7, 2010 at 4:32 PM, David Rosenstrauch dar...@darose.net wrote: I upgraded my extremely not-up-to-date server last night (523 packages upgraded). The upgrade generally went well, except for one significant issue: the keyboard is no longer working under Xorg. It works fine in a command line tty though (i.e., ctrl-alt-F1). Not sure what the problem is, as it was working before the upgrade, and I'm fairly certain I've got all the relevant bits installed and loaded, such as: * evdev module loaded * dbus daemon running * hal daemon running * xf86-input-evdev package installed etc. Perhaps related: I saw the following odd sequence of messages in the Xorg.0.log: (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event2 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event3 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us Certainly sounds like that could be the cause, but I have no idea why that's happening or how to fix. Anyone have any ideas? Can you attach full Xorg log and config ? And does it work with xf86-input-keyboard driver ?
Re: [arch-general] keyboard not working in Xorg after package updates
On Wed, Apr 7, 2010 at 7:59 PM, David Rosenstrauch dar...@darose.net wrote: Anybody have any ideas on this? GUI is completely unusable on the server until I solve this! :-( I really have zero idea what's going on. And it's a difficult thing to find good specific search terms for, as there's been numerous problems with xorg and keyboards over the years that keep coming up in the search results. Well I already suggested a workaround : find a way to use the keyboard driver It should be possible to create a xorg.conf to specify that. Or to edit the hal files, but that's already deprecated with 1.8 Or maybe just removing evdev would work, I am not sure. But you would need mouse too. But in any cases, have a look at http://www.x.org/wiki/ Reporting problems, asking questions and getting help
[arch-general] nvidia with latest Xorg
On Wed, Apr 7, 2010 at 7:35 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 04/07/2010 09:55 AM, David Rosenstrauch wrote: On 04/07/2010 10:46 AM, Xavier Chantry wrote: Can you attach full Xorg log and config ? I'm not using any xorg config. Log is at: http://www.darose.net/Xorg.0.log And does it work with xf86-input-keyboard driver ? I have xf86-input-keyboard installed. I assumed X was just automatically choosing evdev (as I have no xorg config). Thanks, DR On the same note, after the latest Xorg update, X (nVidia card) was failing to start on the same xorg.conf I had used with my arch box since I first installed arch. The xorg.conf was generated by the nvidia-xconfig app. The xorg.conf was: http://www.3111skyline.com/dl/dt/X/xorg/xorg.conf.sav Something is not as it should be in the latest X release. (p.s. this is 'in addition to' and not 'in lieu of' the current topic) This is a complete thread hijacking, has nothing to do with the current topic, and adds NOTHING to it. darose updated to the Xserver in EXTRA which is 1.7.5.902-1 nvidia works fine in extra, even in testing ! It only needs Option IgnoreABI True with xorg 1.8 which is a separate experimental repository AND that was already documented in its announcement : http://mailman.archlinux.org/pipermail/arch-dev-public/2010-April/016387.html
Re: [arch-general] Getting X running on new install (Ionut Biru)
On Wed, Mar 31, 2010 at 9:14 AM, Alain Muls alain.m...@gmail.com wrote: That is exactly what I did. I am not a beginner and have read quite some articles about Arch and I am aware of the fact that I have to follow carefully all steps in this installation process. So pleas bear with me and hep me over this problem. Since it failed I tried to identify the card (I did not know the lshw command before) and redid the steps with the driver for the nvidia-96xx card. Again no X-screen. I also copied the xorg.conf from Ubuntu over to Arch but again no X server that would run. I also tried the nouveau driver and he is given as error: (EE) [drm] failed to open device (EE) No devices detected. Fatal server error: no screens found It is the second time I try to install Arch, I really want to try out this rolling principle, but again I am unable to get up the X server which is working without flaws in Ubuntu. Your card is recent, you don't need the 96xx series, though that should work as well. It seems that in both cases (nvidia or nouveau), the module is not loaded properly. First choose the one you want, and uninstall/remove the other completely, as they both conflict with each other. e.g. if you go with nvidia # pacman -R nouveau-drm check which modules are loaded # lsmod if you see nouveau or nvidia, then rmmod them # rmmod nouveau # rmmod nvidia Then load the kernel module # modprobe nvidia check its loaded fine # dmesg Then configure and start X
Re: [arch-general] kaffeine [sigh] is there an alternative that:...
On Tue, Mar 30, 2010 at 5:05 PM, Heiko Baums li...@baums-on-web.de wrote: Am Tue, 30 Mar 2010 22:10:22 +0800 schrieb Ian-Xue Li da.mi.spi...@gmail.com: As for MOC, I recommend cmus over MOC because it got more decoder over different types files. Well, just tried cmus. It's so complicated an unintuitive. If I need to first finish my degree to be able to use a program then there's something wrong with it. If I add a directory to the playlist, there are no tracks listed in the playlist, only the directory, and the tracks are played in random order, there's no progress bar, etc. And to do simple things, you first need to enter complicated vi like commands. I hate vi, btw. And my impression is that the sound quality of MOC is still a bit better. I doubt that one need the other decoders. At least I haven't missed a decoder in MOC. Heh cmus is probably my preferred player now so I ought to defend it. Too complicated, seriously ? The only command I ever need is the initial one to add my music directory : # add files, short for ':add ~/music' :a ~/music After that, all you need is 3 keys : space to expand an artist and view the albums, enter to play what you want, tab to switch between album view and track view if you want a particular track. By the way, in the main/default mode, you don't see directory, you see artist/albums from tags. There are 7 views in cmus. Press keys 1-7 to change active view. Library view (1) And these 5 shortcuts can be useful too : x player-play c player-pause v player-stop C toggle continue s toggle shuffle You cannot pretend you want keyboard controls, and not open the man page to learn the few keys you need :)
Re: [arch-general] kaffeine [sigh] is there an alternative that:...
On Tue, Mar 30, 2010 at 7:26 PM, Heiko Baums li...@baums-on-web.de wrote: Am Tue, 30 Mar 2010 17:54:48 +0200 schrieb Xavier Chantry chantry.xav...@gmail.com: Heh cmus is probably my preferred player now so I ought to defend it. Too complicated, seriously ? The only command I ever need is the initial one to add my music directory : # add files, short for ':add ~/music' :a ~/music :add command: As I said complicated vi like commands. I did say some people like me only need it once. I put my music only in one directory, I don't think it's so uncommon. In MOC you have a file and directory list on the left and a play list on the right side. You just need to move the selection bar with the cursor keys and press a for add to add a file or a directory recursively to the play list. And to remove a song from the playlist you just need to press d for delete. Toggling between the two lists is possible with tab. Btw., I'm not a friend of those libraries. I organize my audio files on my hard disk with directories and subdirectories. One directory for the interpreter and one subdirectory for the album. With those libraries I usually have chaos and have much more problems finding my files, because they don't work correctly and/or the tags are not filled correctly and consistently. http://easytag.sourceforge.net/ After that, all you need is 3 keys : space to expand an artist and view the albums, enter to play what you want, tab to switch between album view and track view if you want a particular track. By the way, in the main/default mode, you don't see directory, you see artist/albums from tags. There are 7 views in cmus. Press keys 1-7 to change active view. Library view (1) And these 5 shortcuts can be useful too : x player-play c player-pause v player-stop C toggle continue s toggle shuffle In MOC: Enter play p pause s stop n next b back S toggle shuffle Somehow much more intuitive, isn't it? Maybe you should look up where z x c v b are in a qwerty layout and what they do, and it will suddenly looks more intuitive and practical. If you're not on qwerty, you can rebind them. You cannot pretend you want keyboard controls, and not open the man page to learn the few keys you need :) I read the man page. But in MOC you just press h to toggle between the player and a quick help about the shortcuts. MOC has a man page, too, but not for the shortcuts. It's more for infos about configuration or using it with lirc. Settings view (7) Lists keybindings, unbound commands and options. Remove bindings with D or del, change bindings and variables with enter and toggle variables with space. And MOC has a progress bar, shows the file format, the bitrate and some other infos. I have no need for a progress bar, this is enough for me, both more informative and shorter : 00:07 / 03:14 I don't know if it can display file format and bitrate, I don't care much and I have other ways to find this information the rare times I need it. I don't know if cmus has them, but MOC has themes. It has themes too. I have nothing against MOC, I like it too, just wanted to clarify a few things about cmus in case some people want to give it a try. No big deal, really.
Re: [arch-general] [arch-dev-public] [signoff] grep-2.6.1-1
On Mon, Mar 29, 2010 at 8:14 PM, Xavier Chantry chantry.xav...@gmail.com wrote: A very quick look at the git repo : http://git.savannah.gnu.org/cgit/grep.git/commit/?id=54d55bba41f2ff31682fe6523ef6f49b37a0e20f I just love these easy to browse web interface :) 2.6.2 released which includes that fix among others : http://savannah.gnu.org/forum/forum.php?forum_id=6262 ** Bug fixes grep -F no longer mistakenly reports a match when searching for an incomplete prefix of a multibyte character. [bug present since the beginning] grep -F no longer goes into an infinite loop when it finds a match for an incomplete (non-prefix of a) multibyte character. [bug introduced in 2.6] Using any of the --include or --exclude* options would cause a NULL dereference. [bugs introduced in 2.6] ** Build-related configure no longer relies on pkg-config to detect PCRE support.
Re: [arch-general] [arch-dev-public] [signoff] grep-2.6-1
On Thu, Mar 25, 2010 at 11:02 AM, Allan McRae al...@archlinux.org wrote: Upstream big update. Local changelog: - Removed the multibyte locale speed-up patch (and all the patches to fix the issues it created...) as it is now included upstream. - Removed the other patches as it appears they are not being considered upstream. Upstream NEWS: * Noteworthy changes in release 2.6 (2010-03-23) [stable] ** Speed improvements grep is much faster on multibyte character sets, especially (but not limited to) UTF-8 character sets. The speed improvement is also very pronounced with case-insensitive matches. That's awesome. After all these years, I thought this would never happen :) I did a quick benchmark before and after, and I got very similar results, so we are good. grep -i is still considerably slower than grep in UTF-8 (0.1 - 1.5s , that is 15x slower), but IIRC it was MUCH worse with an unpatched grep 2.5, like hundred of times slower. With LANG=C , grep and grep -i are both at 0.1s.
Re: [arch-general] gsfonts - package is updated?
On Fri, Mar 26, 2010 at 12:07 AM, Giovanni Scafora giova...@archlinux.org wrote: Il 26/03/2010 00:02, Ng Oon-Ee ha scritto: Repository : extra Name : gsfonts Version : 1.0.7pre44-1 Installed : 8.11-5 URL : http://sourceforge.net/projects/gs-fonts/ I'm assuming this is a simple mess upstream on non-consecutive version numbers? The linked sourceforge page still lists 8.11 as the stable version, while the one currently in extra is listed as 'pre' (and doesn't seem available in the sourceforge page? I guess that maintainer forgotten the force option. svn log message says Use newer version of the fonts as provided by Fedora's package urw-fonts Fixes FS#10593 It's indeed all well explained in the two comments of that bug : http://bugs.archlinux.org/task/10593#comment59554
Re: [arch-general] [signoff] dmraid-1.0.0rc16-3
Tobias, did you receive the last mail from dmraid developer ? It seems we can solve this problem in a better way now with just a runtime option. And keep just the dynamic binary. I will see if I can get that running and working. Or do you still want to temporarily re-add static dmraid despites that last minute information ? In this case tell me as well and I will test your package. On Thu, Mar 18, 2010 at 10:04 AM, Tobias Powalowski t.p...@gmx.de wrote: HI, readded static dmraid again to fix: http://bugs.archlinux.org/task/18348 please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org
Re: [arch-general] Ignoring packages and piecemeal updates
On Wed, Mar 17, 2010 at 7:42 PM, Denis Kobozev d.v.kobo...@gmail.com wrote: Hi archers, It has been repeated a lot of times that doing piecemeal updates with pacman -Sy pkgname is not a very good idea. What about ignoring packages? Is it as dangerous? And a more general question: is it even theoretically possible to have a bleeding edge distro with piecemeal updates and with no required manual intervention during updates or is it just a pipe dream? Just a pipe dream.
Re: [arch-general] Arch Linux security is still poor....
On Mon, Mar 15, 2010 at 11:18 PM, Magnus Therning mag...@therning.org wrote: After a quick look at it I don't see much that would apply though. Arch doesn't have releases. Arch follows upstream releases very closes (in some cases even too closely ;-) So, if there is no need for backporting to a set of packages that has been blessed into a supported release, what is left to do for a dedicated security team? 1) what allan said : A group could monitor security issues and file bugs to get the devs to fix them. 2) resume and finish the gpg work for pacman friends
Re: [arch-general] Arch Linux security is still poor....
On Mon, Mar 15, 2010 at 11:42 PM, Magnus Therning mag...@therning.org wrote: 1) what allan said : A group could monitor security issues and file bugs to get the devs to fix them. Is there any evidence that this is actually needed? No, Allan asked for some numbers, and I am curious too. My impression is that maintainers already are monitoring upstream releases. When they are lagging, there are users who mark things out-of-date. The occasional non-maintainer upload doesn't seem to warrant a dedicated team. 2) resume and finish the gpg work for pacman friends Sure, that is worth doing. Is it really a task for a dedicated security team? It sounds more like a one-time thing for a group of developers. This is also true.. more or less. It does not matter how the people doing the work are called. There is no one writing code, no one giving technical advices, no one testing. There are only users asking for signed packages.
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
On Sat, Mar 13, 2010 at 2:54 PM, Allan McRae al...@archlinux.org wrote: I do not see all reopen requests, but the need to beg seems overstated... I do know that it is much, much easier to get a bug reopened if the request is clear and well justified. A large portion of reopen requests provide no information to properly judge their merit in which case they are more likely denied. The tiny size of the reopen textbox does not give a lot of freedom for justifications either. I think this is completely missing the point though. I don't understand why Dan is the only developer who sees that it sometimes makes sense to provide additional information on closed bug reports. (update : just saw there is also Pierre) If a bug becomes completely useless and irrelevant when it is closed, why keep it at all ? flyspray could just delete it. The moment a bug is closed is not the moment it becomes history, I can see plenty of cases where one might want to look back at a closed bug (and possibly complete or correct its contents). Now if you (and other dev) tells me that you do see that value, but there are more drawbacks caused by the big number of stupid arch users, then ok... the situation is just sad. But even then, if we consider these situations : 1) Stupid user Either keep posting stupid comments or requesting re-open. The developer just ignores it either way. Is there really a big difference between the two ? We not only assume users are stupid and will flame, but also that they will keep doing that eternally even if no one answers ? 2) Good user Won't post good additional informations because it's not possible. The reopen request just does not cut it. Anyway this is too much arguing for a relatively minor issue. Comments on closed bugs have the potential to be useful occasionally, that's all there is to it. And we are just talking about a flyspray option which can be turned on/off anytime without drawback ? It's not like it's a decision that can cause eternal pain. When it does reach the point where a developer is pissed off, you have your proof that comments on closed bugs is a bad thing, and you can justify disabling this feature. Thanks for accepting my reopening request, you can close the bug now :) Oops, cannot be done on the ML.
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
On Fri, Mar 12, 2010 at 11:39 PM, Allan McRae al...@archlinux.org wrote: On 13/03/10 08:35, Aaron Griffin wrote: Does anyone have an opinion on this? In my eyes, I imagine the kind of people who want this feature simply wish to argue about the closing. I've had to deal with enough PM requests in the past to know that this _does_ happen. Opinions? I really do not see the need. If a bug is wrongly closed - request a reopen. If you just want to confirm a bug has been fixed, there is no need... we already closed the bug report. If there is a better fix, reopen request or new bug report. Closing bugs should not be a race, I had several times the feeling that a bug was closed too fast and it can indeed be annoying. Ideally the one who opened the bug should give an ACK for having their bug closed. There is always something to say. At least a confirmation that the bug was fixed. Eventually a comment about how it was fixed. And you might have additional information / explanation / clarification that is mostly interesting for the people who followed that bug. It seems completely stupid to need a reopen request just to do that.
Re: [arch-general] what is the procedure when your find an out-of-date package in AUR?
2010/3/11 David C. Rankin drankina...@suddenlinkmail.com: On 03/11/2010 09:50 AM, Ng Oon-Ee wrote: If all else fails, blame Allan. Oh, and tell the maintainer what failed. Gotcha! I just posted the new PKGBUILD files as 'comments' to the AUR package and sent Chris (the maintainer) an email telling him what I'd done. Hopefully he can move cut and paste the new package versions and md5sums into the official PKGBUILD files and remove the out-of-date flag. I figured I'd give it another week before I started blaming Allan :p You should probably have done the opposite : - in AUR comments, just quickly state what needs to be changed / fixed - in the email , include the proper attachments Pasting a pkgbuild in aur comments is ugly, takes a lot of space and usually screws up the formatting enough to make it unusable in a very confusing way.
Re: [arch-general] A suggestion for the devs regarding rebuilds
On Wed, Mar 10, 2010 at 11:45 PM, Allan McRae al...@archlinux.org wrote: Not really... The problem is that pacman does not clean up packages installed as a dependency for a package that are no longer needed due to an update which removed that dep. And by the way, we cannot be 100% sure that the 'no longer needed dependency' is not useful in itself. A package foo might have been installed as a dep for package bar, but it can also have some other purposes, unknown to pacman. I don't know if this is just a theoretical problem that has no practical value. But well.. pacman -Qtd exists for a reason..
Re: [arch-general] svn packaging, abs = git ?
On Tue, Mar 9, 2010 at 1:04 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: It seems like this is a solution that's looking for a problem to happen. As far as I know, working with svn isn't a big deal and isn't a problem. Just a side-note : I discovered git svn today, it's really a blessing ! I very rarely hack on any svn projects, but today was the case, and I am not able to do anything with svn. But there is a simple explanation to that : git is the only scm I learned and used. I wouldn't argue whether Arch packages should use git or not simply because I don't know better and I don't have any precise ideas how everything would work. So anyone in the same situation is invited to do the same :)
Re: [arch-general] svn packaging, abs = git ?
On Sun, Mar 7, 2010 at 7:55 PM, Dieter Plaetinck die...@plaetinck.be wrote: On Sun, 07 Mar 2010 19:51:30 +0100 Stefan Husmann stefan-husm...@t-online.de wrote: 4) users can check out older versions of packages easily, with limited storage overhead. Do you want to store binary packages in the git repo? Maybe I misunderstand you. Checking out older PKGBUILDs would be doable in svn also, I guess. no, i was talking about the source packages (pkgbuilds, install files etc). now you can get all that stuff with ABS, but only the latest version. uhm ? Ray already showed you can obviously do that with svn as well, and you even answered to him :) http://wiki.archlinux.org/index.php/Getting_PKGBUILDS_From_SVN
Re: [arch-general] svn packaging, abs = git ?
On Sun, Mar 7, 2010 at 10:14 PM, f...@kokkinizita.net wrote: On Sun, Mar 07, 2010 at 02:49:01PM +0100, Thomas Bächler wrote: The only viable solution I could think of is using one git repository per package - and that is just crazy. I wonder, is it really that crazy ? I've been looking into git as a replacement for my own use. One repo per project seems the 'natural' way to use it. Downloading the complete abs would require a lot of 'git clone' operations, but is that the typical use case ? I guess it is not. And if you really need everything you do it once, after that it's just updates. And most users probably don't need everything. Also, even if I find it hard to believe, it seems that git repos are typically much smaller than the equivalent in svn. I have grepped the full abs tree many times for various reasons. It is very practical. And in 95% of the cases, I do not need any history, I just need the last version to read/edit/rebuild.
Re: [arch-general] top posting
On Fri, Mar 5, 2010 at 12:57 AM, Denis Kobozev d.v.kobo...@gmail.com wrote: Bottom posting shows its downside only when you recently joined a mailing list, for example - you start receiving emails from threads that have been going for a long time and you have no idea what people are discussing. But if you're really interested, you can always use the archive. Using the archive might actually be nicer than reading backward a huge discussion that has been going for a long time.
Re: [arch-general] kernel 2.6.33-1
On Sun, Feb 28, 2010 at 11:56 AM, Allan McRae al...@archlinux.org wrote: On 28/02/10 19:10, Roman Kyrylych wrote: On Sat, Feb 27, 2010 at 16:46, Tobias Powalowskit.p...@gmx.de wrote: Hi guys, kernel 2.6.33 first test run ... Enjoy have fun and give me feedback, I have Intel 965GM video and I get this: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/LNXVIDEO:01/input/input5 ACPI: Video Device [VID1] (multi-head: yes rom: no post: no) [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter video.allow_duplicates=1if the current driver doesn't work. However, I don't see any consequences. Everything works as usual, so perhaps this is not new, I just don't check the dmesg often. I now have that after the update too and can not remember seeing it earlier. Allan See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c504f8cb68eb0d6cde53ba043daff8cb34586493 and http://bugzilla.kernel.org/show_bug.cgi?id=13577 If your display is still fine and brightness control works, I suppose you can safely ignore that.
Re: [arch-general] Archwiki - Installing with fake raid - really chopped up...
On Sun, Feb 28, 2010 at 10:57 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, I don't know who does the wiki editing on the Installing with Fake RAID page, but a lot of the helpful information was deleted and it has been edited down to the point that it is confusing. You seriously don't know that wikis have an history ? And I don't understand what you are saying. I did my first fake raid install recently, probably in December with a recent version of that page and didn't have any problems. I was even surprised it worked on the first try. I just checked how that page was last October, and from the quick comparisons I just did, the current page still contains the same amount of information, has a nicer layout, and does not have some useless and outdated and confusing sections anymore.
Re: [arch-general] [arch-dev-public] Samba package sizes
On Sat, Feb 27, 2010 at 11:54 AM, Rogutės Sparnuotos rogu...@googlemail.com wrote: Dan McGee (2010-02-26 19:09): Guys, does anyone else think this is getting out of hand? ... Seriously, 45 f-ing MB for samba? How can that be possible? ... Samba is growing up fast. It is long known upstream ( http://bugs.debian.org/474543 ) and already anecdotal: http://lists.samba.org/archive/samba/2009-December/152549.html I just read the debian bug, it would be interesting to have a status update after one year : 1) there was a big size increase between 3.0 and 3.2 , how does 3.4(.6) compare to that ? 2) whats up with the librpc/gen_ndr Patches welcome ?
Re: [arch-general] [arch-dev-public] Fwd: FS#17503: [unzip] zsh completion missing for unzip patches
On Fri, Feb 26, 2010 at 8:20 PM, Thayer Williams thay...@gmail.com wrote: Bumping this for feedback. 7z correctly unzips localized win32 zip files, but bsdtar/unzip cannot. Is that good enough to remove the conflicting win32 patches from unzip? Links to feature request for adding support to bsdtar / unzip would be good. If I understand correctly, there should already be some for unzip. And what about bsdtar ?
Re: [arch-general] Xscreensaver corrupts ext4 / partition
On Sun, Feb 21, 2010 at 9:59 PM, Javier Vasquez j.e.vasque...@gmail.com wrote: Bad thing it's still kind of unknown how to solve or to work around it. Well, the work around is not to use xscreensaver, :-(. I don't remember if I can get xlockmore to lock when there's no activity... Well, I'll have to look into something different than xscreensaver then. More amazing, why does the problem only manifests with xscreensaver? There's no problem with any other application... Any ways, I just wanted to provide update. Are you using a GL screensaver ? If yes, then why ? :) Are you running any other GL apps ? Maybe have a look at http://bugzilla.kernel.org/show_bug.cgi?id=14535
Re: [arch-general] powertop vs archlinux vs ubuntu
On Mon, Feb 22, 2010 at 12:42 AM, Stefano Z. mie.iscrizi...@gmail.com wrote: hi i've bought a new notebook (hp pavilion dm1-1150sl) and installed archlinux. i have see a strange thing with powertop, i'm running the vanilla arch kernel26, and i have see this behaviour: Cn Avg residency P-states (frequencies) C0 (cpu occupata) (31,6%) C0 0,0ms ( 0,0%) C1 mwait 0,1ms ( 0,7%) C4 mwait 0,0ms (67,8%) Wakeups-from-idle per second : 31483,5 interval: 10,0s --- as you can see, i have a LOT of wakeups per seconds very low c1 states lot of c0 and c4 states, a wattmeter tell me that archlinux consume about 25/26watt Then i have boot a live ubuntu distro and see this: Cn permanenza media P-state (frequenze) C0 (cpu occupata) ( 0,6%) polling 0,0 ms ( 0,0%) C1 mwait 26,7 ms (68,6%) C4 mwait 1,2 ms (30,8%) Wakeup-da-idle al secondo: 281,3 intervallo: 15,0s --- as you can see the wakeups are a LOT lower than on arch and we have lot of c1 and c4 state, power consumption is about 20W, the same that i have with win7 (about 18/20w). For meaning about cX state see here: http://www.lesswatts.org/projects/powertop/powertop.php thanks! You didn't give enough information so we will need to check the basis : - which cpufreq driver and governor are you using in both cases (check cpufreq-info) - what processes does powertop show as causes for wakeups ? - what processes does top show in term of cpu usage ? Here is what I got in the last few minutes when i was writing this : C4 mwait 3.4ms (92.5%) 800 Mhz98.0% Wakeups-from-idle per second : 279.4interval: 10.0s I have a core 2 duo with acpi-cpufreq loaded and conservative governor. $ grep cpufreq /etc/rc.conf MODULES=(acpi-cpufreq) DAEMONS=(syslog-ng net-profiles crond dbus hal alsa cpufreq storage-fixup) $ grep governor /etc/conf.d/cpufreq # valid governors: governor=conservative
Re: [arch-general] new libdrm breaks nouveau
On Thu, Feb 18, 2010 at 12:00 AM, Ray Kohler ataraxia...@gmail.com wrote: Downgrading libdrm makes X work again. Is this already being worked on, or should I open a bug? If so, against which package, libdrm or xf86-video-nouveau? You need to upgrade and rebuild both xf86-video-nouveau and nouveau-drm. File a bug against these two packages requesting a rebuild bump.
Re: [arch-general] VIM history
On Fri, Feb 12, 2010 at 11:16 AM, Nilesh Govindarajan li...@itech7.com wrote: Or add the following to .vimrc or /etc/vimrc: runtime vimrc_example.vim to enable other features that you are probably used to Yeah this is a lot better :) I started by just including it with runtime. But finally I find it nicer to use /usr/share/vim/vim72/vimrc_example.vim as a base for the ~/.vimrc config file. That way the config might also be more portable between systems.
Re: [arch-general] Error message on mkinitcpio
On Thu, Feb 11, 2010 at 10:27 PM, Dan McGee dpmc...@gmail.com wrote: I think we may have this fixed in pacman-git, but Nagy or Xavier would know for sure... That documentation from man PKGBUILD still applies, I don't think we ever considered it as a bug/problem : replaces (array) An array of packages that this package should replace, and can be used to handle renamed/combined packages. For example, if the j2re package is renamed to jre, this directive allows future upgrades to continue as expected even though the package has moved. Sysupgrade is currently the only pacman operation that utilizes this field, a normal sync will not use its value. But now I am wondering if replaces could imply conflicts/provides. Implicit fields means less control and power to the user/packager though.
Re: [arch-general] KMS again with 2.6.33?
On Tue, Feb 9, 2010 at 9:00 AM, Jan de Groot j...@jgc.homeip.net wrote: The point is that it moved to the staging tree now, where further development will take place. After a while, there won't be an out-of-tree version anymore because all development happens in the official kernel git tree. An example of this is intel: there's several kernel trees around with intel drivers, but no possible way to build intel drm out of tree. All development happens in that git tree : http://cgit.freedesktop.org/nouveau/linux-2.6/ This is then merged to drm-next and then to linus tree. If you just fetch that, you indeed cannot do an out-of-build tree, you have to build the whole kernel. But it's possible to write a Makefile that makes it possible : http://cgit.freedesktop.org/nouveau/linux-2.6/plain/nouveau/Makefile?h=master-compat This Makefile allows to only build the relevant drm/nouveau code, and apparently also to create an archive of it. I don't see why this should stop being possible, and why it would not be possible to do the same with other drivers.
Re: [arch-general] A suggestion for the devs regarding rebuilds
On Tue, Feb 9, 2010 at 3:19 AM, Arvid Picciani a...@exys.org wrote: if someone actually posts patches or other constructive stuff, please CC me. We're rewriting pacman anyway and looking for a solution to handle this mess in particular. Right now the only idea i got is versioned deps which is sort of flawed since that would assert a certain awareness upstream. And if we had that, we didnt have the problem in the first place... maybe there is a smarter way to force update of packages that would break when their dependencies are updated. If people actually read my 10 lines mail, and spent more time to think and less time to write, maybe the thread could have gone forward rather than backward ? The last discussions on the sodepends/soprovides proposal are there : http://mailman.archlinux.org/pipermail/pacman-dev/2010-January/010386.html http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/ It's not the first time I regret posting to arch-general, I should have kept this on pacman-dev only, discussions tend to be much more constructive there with much less noise. Anyway, care to explain what you are rewriting pacman for ? There are probably plenty of good reasons to do that, I am just curious to know if you have any :)
Re: [arch-general] A suggestion for the devs regarding rebuilds
On Tue, Feb 9, 2010 at 11:08 AM, Allan McRae al...@archlinux.org wrote: On 09/02/10 19:50, Xavier Chantry wrote: Anyway, care to explain what you are rewriting pacman for ? There are probably plenty of good reasons to do that, I am just curious to know if you have any:) I guess it is for some ideas here: http://www.hereticlinux.org/wiki/pacideas # user can then diff /usr/etc/foo.conf /usr/etc/foo.conf and take action I don't expect to see much differences between /usr/etc/foo.conf and /usr/etc/foo.conf, do you ? :P Anyway, nothing interesting there, but also nothing justifying a rewrite. Minor hacks at most.
Re: [arch-general] [arch-dev-public] package signoffs
On Tue, Feb 9, 2010 at 7:59 PM, Eric Bélanger snowmanisc...@gmail.com wrote: One reason that it takes time to get signoffs for certain packages is that we don't know if enough devs use it to get the required signoff. For instance, I don't use openvpn. How many devs use openvpn? I don't know and probably no-one does. A while ago, I started this: http://wiki.archlinux.org/index.php/DeveloperWiki:CoreSignoffs#List_of_potential_signees_for_low-usage_core_packages to fix that issue but basically no-one bothered to fill it up. If we would know how many dev use these low usage packages, then we could automatically send the signoff thread to both the dev ML and to the arch-general ML and specifically ask for users signoff instead of waiting for dev signoffs that will never come. That's what I was thinking about, how to get more people involved for signoff. You could either ask more often for user signoff on arch-general, or maybe give the status of testers to some active arch members who use testing (if any users are interested at all..)
Re: [arch-general] KMS again with 2.6.33?
On Sat, Feb 6, 2010 at 12:56 PM, Tobias Powalowski t.p...@gmx.de wrote: It will be supported as .33 will ship kms. Right now .32 supports kms for ati and intel cards, nouveau is optional. It seems the question was not only about kms but also about dri2, which is needed to get 3d support with kms. About nouveau, ums was dropped from ddx on 11th January and extra/xf86-video-nouveau package is from 17th January. So the only option is to use kms, which should also be enabled by default now.
Re: [arch-general] A suggestion for the devs regarding rebuilds
On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick jdho...@gmail.com wrote: Hey all, I have a suggestion to possibly make rebuilds a bit less painful (or non-existant). I think this is a good idea because it seems like right now, even before there was a new rebuild (ffmpeg/x264) in testing, there's already another on the horizon (linjpeg/libpng, and it's a big one) and when this isn't the case, there's usually a rebuild, when it leaves testing, another rebuild comes in within days and so on. My suggestion would be to do what Debian does and when there's a library release with a new soname, bump the old package and rename it (or for new packages just do it from the start) and make the package name include the soname version (like libjpeg7, libpng12, libtorrent-rasterbar4 and so on) and when the soname is bumped upstream, just make libjpeg8 or libpng13 or libtorrent-rasterbar5. This does clutter the repos a bit, but it pretty much negates the need for rebuilds since (i believe) when the new GNOME for example is released, it'll automagically build against libjpeg8 and libpng13 instead of the old ones and eventually, almost no packages will be using the old ones. Once the package list for a large rebuild like the libpng/libjpeg one is down to 3 or 4 items after like 3 months, you can probably rebuild them and pull libjpeg7/libpng12 from the repos. This is one of the single biggest things I hate about apt based distros. The libfoo2/libfoo3/libfoo4 cruft. It's needless. This doesn't do anything with regards to helping the devs do rebuilds, because packages still need to be rebuilt. It just allows us to take our time - something you DON'T want if you're expecting packages to be up to date. With every big rebuilds we get new breakage stories. It seems like it's the norm nowadays rather than the exception. I am wondering if it's really only the users that are to blame.. or if Arch is also to blame. Or if Arch was supposed to be an elitist distribution and is victim of its success. More importantly, I am wondering if the sodepends/soprovides proposal would not actually be a more complex solution than the libfoo2/libfoo3/libfoo4 way.
Re: [arch-general] KMS again with 2.6.33?
On Tue, Feb 9, 2010 at 12:50 AM, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2010-02-08 at 18:52 +0100, Xavier Chantry wrote: It seems the question was not only about kms but also about dri2, which is needed to get 3d support with kms. About nouveau, ums was dropped from ddx on 11th January and extra/xf86-video-nouveau package is from 17th January. So the only option is to use kms, which should also be enabled by default now. Which means autoloading of nouveau modules by udev, which means breaking the nvidia drivers for everyone not blacklisting it. This is going to be so much fun... especially now nouveau was merged in the staging tree. That's true, but the conflict goes both way. And the situation isn't different with ati vs fglrx, is it ? Anyway, there is no reason to enable nouveau in the kernel, the current out-of-tree build is just fine and allows for more frequent updates. As long as users still have to install it explicitly, they should be able to handle this conflict. But it would indeed be more problematic if we wanted to have it directly in the kernel package.
[arch-general] Eben Moglen's view on mkisofs GPL (non-)compliance
I also hope this helps somehow. -- Forwarded message -- From: Karl Berry via RT licens...@fsf.org Date: Sun, Feb 7, 2010 at 1:42 AM Subject: [gnu.org #544172] Fwd: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit To: chantry.xav...@gmail.com Hello Xavier, Eben just sent me this summary of his discussion with Jörg Schilling on the subject of the cdrtools mkisofs. He said that it can be republished/posted anywhere. When/if you do that, please do so *in its entirety*. All too easy for things to be taken out of context, so let's at least get the full version out there. Hope this helps somehow. Thanks, k...@gnu.org Date: Sat, 6 Feb 2010 11:24:23 -0500 From: Eben Moglen In September 2008, I was asked by Mark Shuttleworth if I could help Canonical discuss with Jörg the measures necessary to include cdrtools in Ubuntu. I spoke to Jörg by phone at first to explain my role, and then by email. I reminded him in doing so that I had agreed with him about the acceptability of combining GPL'd code with a C-library under CDDL in order to make the Debian/GNU/OpenSolaris stack called Nexenta. (I believe this part of our conversation is the source of Jörg's mistaken statement that I somehow indicated that cdrtools is non-infringing, although the issue of the system library exception in GPLv2 is completely distinct from the problem presented by the CDDL-licensed libraries libscg and libschilly combined with GPL'd mkisofs in cdrtools.) After speaking to Jörg we began our review of the complete source of cdrtools, and soon verified that GPL compliance on mkisofs was broken. We told Jörg that as far as we could see he was the only copyright holder on the CDDL'd libraries, which he confirmed. In that case, I pointed out, he could give all the permission necessary to solve the problem, without any license changes: he simply needed to give permission as the relevant copyright holder on the CDDL's libraries for combination with mkisofs and distribution of the binary and source under the terms of GPL, without any additional restrictions. We drafted for him the thirty-nine words needed: You are permitted to link or otherwise combine this library with the program mkisofs, which is licensed under the GNU General Public License (GPL). If You do, you may distribute the combined work under the terms of the GPL. Jörg disputed our analysis. He argued to us: (1) that the binary mkisofs is not derivative of the CDDL-licensed libraries because it merely links to them; and alternatively that (2) CDDL Section 3.6 (Larger Works) permits the combination. He claimed to have German legal advice confirming him on point (1), but without regard to his German legal analysis, which differs from that of our German lawyers, the argument is incorrect as a matter of law, at least in the United States, and GPL'd mkisofs (whose copyright is at stake) is a US work to which US copyright law applies under the Berne Convention. As to his point (2), while CDDL Section 3.6 permits combination with code under other licenses, it nonetheless requires that the requirements of this License are fulfilled for the [combined program]. Since it is impossible to observe certain requirements of the CDDL while simultaneously respecting the GPL's prohibition of additional restrictions (GPLv2 Section 6), the CDDL Section 3.6 permission is insufficient to allow the combination. Hence the permission we advised him to grant. Though Jörg continued to argue that he didn't *need* to grant the permission, he never explained why, in the face of opposing legal analysis on behalf of the copyright holders of mkisofs he didn't *want* to grant a harmless permission that would allow his work to be included in Canonical's Ubuntu distributions. After weeks of discussion and many hours of my time and the time of my associate Aaron Williamson, Mark Shuttleworth decided there was no point in further fruitless negotiation and I agreed. SFLC was not paid for its work by any party.
Re: [arch-general] Multiple Kernels
On Tue, Feb 2, 2010 at 8:53 AM, Ray Rashif schivmeis...@gmail.com wrote: Urmm..if it is so important, Arch gives you the power to roll your own kernel. Heck, I don't even have a fallback, because I don't need it. Like Fons, I have an RT kernel, and a normal kernel. Either acts as a backup of the other, since neither gets updated along with the other. To all the complainers in that thread : WHO has a serious problem with the above, and can give a strong argument WHY ? I completely agree that having only one kernel installed sucks, if that one stops booting, you need a livecd/usb in order to boot and fix things. That simply does not happen if you have two kernels installed, be it RT or LTS or custom or whatever. Now if we are talking about minor issues, the kernel boots and works, then there is no reason the kernel should be handled in a more special way than any other packages. It's not the only critical component of the system. So just follow : http://wiki.archlinux.org/index.php/Downgrading_Packages And I actually find quite annoying the debian/ubuntu handling of accumulating old kernels and having to clean up every time. Final word : if you are not happy with the quality of testing already made for core packages, just HELP to improve the situation.
Re: [arch-general] Multiple Kernels
On Mon, Feb 1, 2010 at 3:59 PM, ludovic coues cou...@gmail.com wrote: WAIT WHAT? http://www.archlinux.org/packages/core/i686/kernel26-lts/ http://www.archlinux.org/packages/core/x86_64/kernel26-lts/ lts is not for everyday desktop usage. Who said anything about desktop usage ? It is useful for a server. And it turns out to also be a nice fallback if your new kernel is very broken. A fallback is not for everyday desktop usage, it's supposed to allow you to boot and fix/report/figure out whatever problem you have with the new kernel.
Re: [arch-general] core/linux-api-headers?
On Mon, Feb 1, 2010 at 10:36 PM, Brendan Long kori...@gmail.com wrote: Sounds like the real problem is pacman's message then. My suggestion: change package x has been replaced by package y to package x has been renamed package y. fork/alternative != rename The term 'replace' is more general than a rename. And it's consistent with the implementation : the PKGBUILD variable is called replaces and the db entry is called REPLACES. Are you all suggesting that we introduce renames/RENAMES in PKGBUILD and in the database ? Because that would make things less confusing ? It looks much more confusing to me.
Re: [arch-general] [arch-dev-public] exim maintainer wanted
On Mon, Feb 1, 2010 at 10:55 PM, Allan McRae al...@archlinux.org wrote: On 01/02/10 13:08, Allan McRae wrote: exim has no maintainer and I have been assigned a bug for it as the last person to rebuild it (db-4.8 rebuild). I do not use it and have no intentions of fixing the bug. Does anybody want to be the maintainer? Anyone? It now has two bug reports, one of which contains a patch to fix both issues. However, me fixing this only means I will be assigned the next bug it has... Allan Just drop it to AUR :)
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Wed, Jan 27, 2010 at 4:51 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot j...@jgc.homeip.net wrote: On Wed, 2010-01-27 at 15:45 +0100, Joerg Schilling wrote: Just to make it clear: There is not a single claim from a lawyer that confirms the claims from the hostile downstram packager. Looking through the thread on the fedora list they claim there's lawyers confirmed it, but in the same thread you say they're not lawyers. Point is, the situation is unclear and all that is done is flaming. People flame you for your weird license, you flame other people for forking your software. Mr Schilling reminds me quite a bit of that Ion guy who was overly hostile and trollish. That clears up the situation just fine for me. Well I thought about that too, and I believe there is one huge difference : tuomov explicitly imposed a lot of restrictions in packaging, and apparently didn't want or didn't care at all if Arch packaged it or not. If it is packaged, it has to be under his terms. If it isn't, who cares. His interest seemed to not have it packaged, as he believes that would mean less problems and less bug reports for him. Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : What is in this for him?. The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord. Even if that's not the case (2 possibilities : wodim is not as broken as Joerg pretends, or arch users are clueless), is Arch really noticeable compared to the big distrib ? I am curious to know if anyone has pointers to estimates of linux distribution userbase, but I doubt Arch would matter. And seriously, if the goal is world domination, making Debian/Ubuntu an enemy is a very efficient way for failing.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Mon, Jan 25, 2010 at 11:40 AM, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2010-01-25 at 11:19 +0100, stefan-husm...@t-online.de wrote: Hello, the only reason I did not move cdrtools to community was that license reason. So if that is no showstopper anymore, I can maintain it. Regards Stefan I just checked alpha10, one of the first versions that was released as CDDL, that also has that exception. It seems that GPL and CDDL have some conflicting paragraphs, so even if CDDL allows linking to GPL with this exception, GPL doesn't allow the other way around. So no, releasing as binary is still not possible when it comes to mkisofs. mkisofs is still plain GPL without exceptions. That could be the reason of this new project... https://savannah.gnu.org/forum/forum.php?forum_id=6137 The link in the announcement is broken, but it is easy to find in the same ftp, and the Download links in the top leads directly to it : http://ftp.gnu.org/gnu/isofsmk/ If mkisofs is the only doubtful part, why not replacing only mkisofs ? Wouldn't that be better than replacing everything ? Joerg already said that mkisofs received the most code changes, and that genisoimage was quite problematic : genisoimage does not support UTF-8 and large files and creates filesystem images with lots of bugs. I am sure he will have plenty of nice things to say about isofsmk as well ! Anyway, if it was up to me, I would not replace anything, I would just provide everything, and give the power to the user. Either all as packages, or all as pkgbuilds in AUR, to not make anyone jealous.
[arch-general] PulseAudio
On Tue, Jan 26, 2010 at 10:28 AM, Ng Oon-Ee ngoo...@gmail.com wrote: If you want to read up on the different sound components, just do a google search. There's tons of articles out there, some very good, mostly a bit crap. Lennart Pottering (dev for Pulse) has a particularly good one I recall. Most on Arch wouldn't like his conclusions though. I collected some article/blogs about pulseaudio, in case anyone is interested. 1) PA detractor (both articles have been slashdotted) http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html 2) PA defenders interview of Lennart Poettering (PA dev at redhat) http://jaboutboul.blogspot.com/2009/05/sound-of-fedora-11.html his blog : http://0pointer.de/blog/projects Many info about PA there, just one example : http://0pointer.de/blog/projects/guide-to-sound-apis.html blog of colin guthr (another PA dev) : http://colin.guthr.ie/tag/pulseaudio/ Also many interesting articles, for example : http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ (answer to 1)) http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-1-alsa/ http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ -- If you are just interested about getting PA working, and not about the how and why, you should probably just read the following wiki, instead of all the links above : http://wiki.archlinux.org/index.php/PulseAudio http://www.pulseaudio.org/wiki/PerfectSetup
Re: [arch-general] problem with video driver ?
On Mon, Jan 25, 2010 at 12:46 PM, f...@kokkinizita.net wrote: Meanwhile I installed nouveau. The only difference I notice is that now the 'visual bell' in xterm has become very slow as well (to the point of being unusable), also locally. I suspect you did not install it properly and were running in noaccel mode. But since you solved your ssh X forwarding problem, and are happy with nv, you can keep using that. If you are still curious about nouveau, you have to install nouveau-drm, xf86-video-nouveau (and nouveau-firmware if you have a GF8 or newer), edit xorg.conf , and then provide dmesg and Xorg logs.
Re: [arch-general] Xscreensaver corrupts ext4 / partition
On Mon, Jan 25, 2010 at 4:36 PM, Thayer Williams thay...@gmail.com wrote: On Sun, Jan 24, 2010 at 7:14 PM, Javier Vasquez j.e.vasque...@gmail.com wrote: Bad thing that xscreensaver corrupted / so that it couldn't be unlocked, and under console there was no way to loging, some misplaced inodes or something... Hard reboot was required, and then at first /tmp was so corrupted that it was necessary a phisical fix... I can't seem to connect the dots here. How do you propose that it was xscreensaver that corrupted ext4? While it does sound like your ext4 partition may be corrupted, that doesn't mean that xscreensaver is to blame; rather it was just another victim. If the partition is corrupted then reinstalling package xyz isn't going to fix it. You need to wipe it and rebuild. AFAIK there are no known issues with xscreensaver corrupting a filesystem and it seems rather unlikely. The much more likely case is that somehow your partition did become corrupted, but it wasn't noticed until some time after xscreensaver kicked in. If it's a filesystem issue and not hardware, then hopefully running fsck will be enough.
Re: [arch-general] problem with video driver ?
On Sun, Jan 24, 2010 at 11:50 PM, f...@kokkinizita.net wrote: Hello all, Today I installed Arch on my desktop which previously had Fedora. All works well except ssh -X zita2 emacs where zita2 is my laptop. It works, but it is ex tre me ly slow, I can count the lines being displayed when scrolling a page. This used to work perfectly before. Other apps doing quite intensive X work don't seem to be affected. OTOH, the emacs running on the laptop is of course the same as before. Video driver is 'nv', but it doesn't show up in lsmod. Some others do: 'drm' and 'ttm' which I haven't seen before. As far as I was able to find out, 'drm' is related to 3D-acceleration. I don't need nor want this, and I'm suspecting it could be related to the problem I'm seeing. Any hints/help will be appreciated ! Are you sure you were using nv on fedora ? nv is indeed extremely slow. Fedora 11 apparently used nouveau as default : http://fedoraproject.org/wiki/Features/NouveauAsDefault You can also install it easily on Arch, just have a look at http://wiki.archlinux.org/index.php/Nouveau
Re: [arch-general] problem with video driver ?
On Mon, Jan 25, 2010 at 1:04 AM, f...@kokkinizita.net wrote: It is the 'ssh -X zita2 emacs' that is very slow. Running emacs locally is perfectly OK. The previous install was F9, it used nv, and the same 'ssh -X zita2 emacs' worked perfectly. Nothing has changed on zita2. As far as I can see, the Arch installation tries to enable 3D-acceleration by installing 'drm'. I don't want it. How can it be disabled ? It seems I read your mail too quickly. But if only apps through ssh are slow, why would you suspect video driver, and not network / ssh speed ? And why would 3d acceleration make your X-forwarded 2d app slow ? By the way, you have no 3d-accel at all with nv, just very basic 2d. And afaik drm does not do anything on its own. It just provides the core of graphic drivers, like nouveau for instance. nv does not use it either. And there is no reason for using nv nowadays, nouveau does better in every aspect ! and nouveau does rely on drm so you will want to keep that. That said you can blacklist whatever you want, just have a look at /etc/rc.conf. You could also try blacklisting your network driver, I am sure it will make everything much faster :)
Re: [arch-general] Quoting of E-mails
On Wed, Jan 20, 2010 at 1:08 PM, Marti Raudsepp ma...@juffo.org wrote: On Wed, Jan 20, 2010 at 1:43 PM, Steve Holmes steve.holme...@gmail.com wrote: Actually when you think about it, most blogs are all in reverse chronical order which to me is the same thing as top-posting and nobody seems to complain about that concept. Separate blog posts are typically unrelated, so there is no reason they should be chronologically ordered. How about blog comments? In nearly all blog publishers, they are in chronological order. I agree, one blog post + comments is more analog to one mail thread. So I like to have the same order as in blogs : threads / blog post in reverse order (most recent on top) , but inside each of them, bottom-posting / chronological order. Actually when you use a thread view, you usually get a chronological order for all mails inside a thread. If you combine that with top-posting, its a bit weird.
Re: [arch-general] Re-installing whole system without touching configs.
On Sun, Jan 17, 2010 at 6:51 PM, Ray Rashif schivmeis...@gmail.com wrote: Often times it's the user configuration files that mess up a system, so keep that in mind unless you're really confident it's all in the packages themselves. And if you're thinking of reinstalling a la pacman -S $(comm -3 (pacman -Qq) (pacman -Qqm)) then remember to put it in a list first, remove them (-Rscn) and then (re)install (-S). This is because some, if not many packages, contain post-remove/install commands that may affect the outcome. I don't know if it's a good idea to remove pacman, libfetch, libarchive, glibc, bash, ... If you are worried some important files got corrupted, a simple reinstall with pacman -S should be fine.
Re: [arch-general] Why Is My RAID Installing Failing?
On Wed, Jan 13, 2010 at 8:22 PM, Carlos Williams carlosw...@gmail.com wrote: On Wed, Jan 13, 2010 at 1:57 PM, Alexander Duscheleit ji...@archlinux.us wrote: I still think /arch/setup *should* generate this file itself if it detects software raids in use for the target. The wiki even seems to suggest, that it does. Could some releng shine light on this, please? I completely agree. The Wiki suggests that it's as simple as self generating if I follow the steps and it clearly is not. I became so frustrated I almost abandoned Arch. I hope this gets fixed in a soon future release of Arch. Where is the link to the bug report ?
Re: [arch-general] [arch-dev-public] OS News interview
The common way is to reply on arch-general, so I will include that list in CC now. Thanks for the clarification. So your concern was not about using external binaries, it was about keeping to use outdated Arch programs. That's also a very good point when talking about disadvantages of the rolling release model. It seems most developers answered purely from a developer point of view more than a user one. But I read the answers again and noticed the overlord did mention both sides :) Aaron Griffin: The biggest problem with the rolling release model is laziness - from upstream developers and Arch users. We try to stay up to date wherever possible, but some upstream developers are slow at adopting new changes. This means we need to do extra work to make their software compatible with new library versions and things of that nature. On the user end, you get people who don't regularly update their system (something we indicate as very important), and you end up with newer software and older libraries on the same system, causing breakages. So I just want to highlight that it's indeed very important to regularly update a Arch system, and it's something that should be made clear when advertising Arch, because it definitely does not fit to everyone. On Tue, Jan 12, 2010 at 5:22 AM, Gregory Eric Sanderson gzou2...@gmail.com wrote: Hi Xavier, I tried to post an answer to your last message, but since i'm only an observer on the dev list I can't. So I'm transfering directly to you my answer if ever it might interest you -- Forwarded message -- From: Gregory Eric Sanderson gzou2...@gmail.com Date: Mon, Jan 11, 2010 at 11:20 PM Subject: Re: [arch-dev-public] OS News interview To: Public mailing list for Arch Linux development arch-dev-pub...@archlinux.org Actually, that question came from me :-) Sorry if the question wasn't clear, I should have phrased it in a different way. Although my country officiaily has 2 languages, I live in the province that speaks almost only french, so I don't get much chances practicing my english. The programs that depend on older libraries who aren't on the system anymore because of an update is actually an example that I was trying to give of a disadvantage that could occur because of the rolling release model. when I switched full-time to Arch, I din't do system upgrades very often and It happend regularly that programs would stop to work because they were linked to libraries who were updated as part of the installation of a new program. (I hardly get this problem anymore since I upgrade more regularly now) Don't get me wrong, I love the rolling release model. But I was curious to know what the developers thought of this and if they saw any other disadvantages or quirks that the rolling release model brought On Mon, Jan 11, 2010 at 6:59 PM, Xavier shinin...@gmail.com wrote: On Mon, Jan 11, 2010 at 11:22 PM, Allan McRae al...@archlinux.org wrote: The OS News interview is up: http://www.osnews.com/story/22692/Arch_Linux_Team Fun interview. Allan's answers are the best, I have to say :) Some comments : - a few formatting issues. like the first reply from Thomas often misses a newline. Allan lost his A and became llan and one page. - whats the difference between these two questions on page 5 : What part of the Arch Linux development is the most active? Where is development primarily focused for the Arch Linux team (the installation, pacman, etc)? - about this question One of the most notable characteristics of Arch is its rolling release model, which assures users that they will always have the latest and newest version of a program available. Has this model brought any noticeable disadvantages (for example: programs that depend on older libraries who aren't on the system anymore because of an update)? I am not sure what the question meant to hint with programs that depend on older libraries who aren't on the system anymore because of an update but that reminded me of several times I tried to run some binaries on Arch, and it failed because all libraries were too new. :)
Re: [arch-general] Quoting of E-mails
On Tue, Jan 12, 2010 at 11:48 AM, Simon Boulay simon.bou...@gmail.com wrote: google e.g. to search for foobar in arch-dev-public: foobar site:http://mailman.archlinux.org/pipermail/arch-dev-public/ (42 hits!) There is also gmane.org: http://news.gmane.org/gmane.linux.arch.devel http://news.gmane.org/gmane.linux.arch.general And many others as google can show you : http://www.mail-archive.com/arch-dev-pub...@archlinux.org/ http://archive.netbsd.se/?ml=arch-dev-public http://n2.nabble.com/arch-dev-public-f2376690.html
[arch-general] gmail and mailing list
On Tue, Jan 12, 2010 at 7:25 PM, Mauro Santos registo.maill...@gmail.com wrote: P.S.: As a sidenote: Is it normal/intentional that I don't get my own mails back via the list? Or is this some weird GMail stuff? It's a gmail issue. I'm not sure if there is a setting or something like that, but i've noticed the same and also heard other people about it. mvg, Guus Same problem here, and they even know about it, they might as well provide some workaround or option to change it. http://mail.google.com/support/bin/answer.py?hl=enanswer=6588 I don't understand how that is an issue. Why do you want to see your own mails in the inbox ? For each ML I subscribe to, I create a new label and a new filter, and I set it to skip inbox and archive because I do not want ML to clutter my inbox. Much better that way :) But to each his own. That said I think it's always better to have configure options and control.
Re: [arch-general] gmail and mailing list
On Tue, Jan 12, 2010 at 7:51 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: I see mine just fine in the Sent folder. I don't think mailman actually sends a list mail to the original sender, does it? Either way, they are threaded together when it becomes a conversation It is apparently a mailman option. Receive your own posts to the list? Ordinarily, you will get a copy of every message you post to the list. If you don't want to receive this copy, set this option to No. It was set to yes for me, that was probably the default, I don't remember ever changing that.
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Wed, Jan 13, 2010 at 12:34 AM, Dimitrios Apostolou ji...@gmx.net wrote: On Mon, 11 Jan 2010, Aaron Griffin wrote: If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them. pacman -Qh -o, --owns filequery the package that owns file -i, --info view package information (-ii for backup files)
Re: [arch-general] wchan info in ps
On Wed, Jan 6, 2010 at 7:04 PM, Dimitrios Apostolou ji...@gmx.net wrote: On Sat, 14 Nov 2009, Dimitrios Apostolou wrote: Hello list, is anyone actually getting WCHAN information from either ps or top? To try it just use ps opid,wchan,cmd. I only get dashes, any idea why? I managed to resolve this issue. Arch builds its kernels (on 32-bit at least) without CONFIG_FRAME_POINTER and loses the ability to produce correct stacktraces, either with /proc/$PID/wchan or with SysRq-t or with gdb. On the other hand it has one more register free so minor optimisations can be performed. Why don't we set CONFIG_FRAME_POINTER=y? WCHAN output is very useful to be lost and frankly I don't think performance losses would be perceivable. Last but not least I haven't seen this disabled in any other distro. Sorry for not answering earlier, but I probably did not have any ideas when reading your previous answers. I am on 64-bit and I have the same result here using Arch kernel. The reason why it worked for me and still works is that I am always using a custom kernel, I use http://cgit.freedesktop.org/nouveau/linux-2.6/ to follow nouveau development. And I have CONFIG_FRAME_POINTER=y because this option is quite important indeed If you say Y here the resulting kernel image will be slightly larger and slower, but it gives very useful debugging information in case of kernel bugs. (precise oopses/stacktraces/warnings) I definitely want to get precise oopses/stacktraces/warnings so that I can report them if needed. Maybe the average arch user also wants to do that, I don't know. You can do some research to find out what the big distrib are using in their default kernel (fedora,suse,debian,ubuntu,...) and/or you can open a bug in Flyspray.
Re: [arch-general] [Request] Remove libpthread-stubs from packages svn/trunk
On Fri, Jan 8, 2010 at 5:36 PM, Thomas Bächler tho...@archlinux.org wrote: Am 08.01.2010 17:24, schrieb a...@nezmer.info: Can someone remove libpthread-stubs from packages svn/trunk? The package obviously was removed from the repos a long time ago and tools like pbget would fetch an outdated PKGBUILD. While you may be right, such tools must be able to handle packages in trunk that are not in any repo: It might happen that packages are being removed from the repos but kept in trunk for some reason (maybe to be readded later, maybe for some other reason). Other packages might be in trunk because they will be used in the future, but have not yet been added. Why doesn't Arch ship that package ? It's a single 6 lines file, it cannot hurt anything. I just realized arch patches libdrm to not require it : http://repos.archlinux.org/wsvn/packages/libdrm/repos/extra-i686/no-pthread-stubs.patch But official libdrm still requires it, and that's also what we get if we just clone libdrm git repo (usually needed if you also build git versions of ddx and mesa). I just asked on #dri-devel about it : 18:01 shining whats the deal with pthread-stubs ? libdrm requires it (apparently with http://cgit.freedesktop.org/mesa/drm/commit/?id=6df7b0719fe92b718e486c2b87e2f883cfa41efa ) but arch kills it (http://repos.archlinux.org/wsvn/packages/libdrm/repos/extra-i686/no-pthread-stubs.patch). do all distrib do that ? 18:03 pq shining, it is for non-threaded applications, so that the library does not call into the real pthread library but gets the no-op stubs instead. It is implemented by glibc, so the stubs package is empty in that case. 18:04 shining pq: is it possible to require it only when glibc is not available/used ? 18:05 pq shining, the pthread-stubs package itself handles that. That's why it exists. 18:05 jcristau shining: what's the point? what's required is a single .pc file at build time in that case 18:06 pq in a glibc system it really installs only a single .pc file, AFAIK 18:07 shining jcristau: I guess I will forward that question to arch if its the only distrib doing that :) if no one has a good answer to jcristau question, I will open a bug report.
Re: [arch-general] [Request] Remove libpthread-stubs from packages svn/trunk
On Fri, Jan 8, 2010 at 6:27 PM, Jan de Groot j...@jgc.homeip.net wrote: On Fri, 2010-01-08 at 18:11 +0100, Xavier wrote: Why doesn't Arch ship that package ? It's a single 6 lines file, it cannot hurt anything. I just realized arch patches libdrm to not require it : http://repos.archlinux.org/wsvn/packages/libdrm/repos/extra-i686/no-pthread-stubs.patch But official libdrm still requires it, and that's also what we get if we just clone libdrm git repo (usually needed if you also build git versions of ddx and mesa). The dependency is killed because it's useless. It's easy to kill, so we do it. If you like to install the package because you want to build stuff from git without killing the dependency from your sources, you're free to install it on your system. Well ok, that's fine... I don't see point in maintaining a package with just a 6-line .pc file. That's also the reason why we don't maintain this package in extra or any other binary repository, it's useless. ...but I don't buy this argument, there isn't any maintenance and cost involved compared to any other packages. And I feel up to the task, it will take 1 minute of my life, but also save a few minutes of my life for the few times I will have to install the aur package on a new system :) Compared to the many hours I spend talking about random useless stuff, I agree it's not much. I just disagree with the principle let's kill 6 lines just because we can but it won't change my life much, so no big deal ! I already forgot about it.
Re: [arch-general] [arch-dev-public] Cron
On Mon, Jan 4, 2010 at 7:35 AM, Heiko Baums li...@baums-on-web.de wrote: I vote for fcron because it has dcron and anacron features. Two separate packages is indeed a regression and not really KISS like because anacron can only do anacron and dcron can only do dcron while fcron can do both. And on a desktop system which doesn't run 24/7 you need both features at the same time. On servers which run 24/7 it doesn't harm if the cron daemon has anacron features, too. Having one tool doing 2 different tasks is quite in contradiction with the KISS philosophy. That said, I think the rest of your argument is valid, kiss isn't the holy grail, sometimes having a tool that is less simple, less stupid and more powerful is a good idea. So going with fcron sounds fine. Confusing simplicity for the user and simplicity for the software just seems way too common.
Re: [arch-general] libglew
On Sat, Dec 26, 2009 at 11:25 PM, Dwight Schauer dscha...@gmail.com wrote: Won't extra/glew work? $ pacman -Ss glew extra/glew 1.5.1-1 A cross-platform C/C++ extension loading library By the way, since Arch does not split binaries/headers/libraries, there are several cases when you need libfoo, you have to look for the foo package in Arch. While Debian for example has glew-utils (binaries), libglew (libraries) and libglew-dev (headers) : http://packages.debian.org/search?keywords=glewsearchon=namessuite=stablesection=all
Re: [arch-general] Kernel 2.6.32
On Tue, Dec 22, 2009 at 12:35 AM, Frank Hale frankh...@gmail.com wrote: I was using the testing kernel 2.6.32 without an issue but then when the kernel went to core my system would no longer boot. It would start to boot half way then just go dead. I don't have any error messages to post because the screen went blank. Grub was working fine as far as I can tell. I had to use the Arch live CD to revert kernels back to an earlier version. Has anyone been having issues with the stable kernel 2.6.32? Like I said, 2.6.32 from testing worked fine. Uh ? It is the same package that moves from testing to core. The move cannot break anything. When you use testing, and a package gets moved, you cannot even notice it, because pacman -Su won't do anything : you already have the latest packages. Maybe you want to be a bit more specific about which version exactly you were using ? If you don't know, you can check pacman logs. The changes to kernel26 can be seen here : http://repos.archlinux.org/wsvn/packages/kernel26/trunk/?op=logrev=0isdir=1 There has apparently been one revision for each stable kernel release so : 2.6.32-1 2.6.32.1-1 2.6.32.2-1 2.6.32.2 contains 5 radeon patches : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.2 If you can actually confirm that this is what broke your setup, this narrows down the issue extremely. The list of changes between 2.6.31 and 2.6.32 is likely awfully huge.
Re: [arch-general] Kernel 2.6.32
2009/12/22 Ng Oon-Ee ngoo...@gmail.com: Something's been bugging me about this email, and I just realized, 2.6.32 hasn't moved to core yet! Ah ah, right. I thought it could have moved, since it seemed to be ready and got a few signoff. And Frank said it moved. I assumed it was just the package web page that wasn't up-to-date (I believe I already saw that a few times), but usually the websvn view is up-to-date and I didn't check it carefully. My mistake.
Re: [arch-general] A universal Operating System API - why don't we have it?
On Fri, Dec 18, 2009 at 5:31 PM, Chris Brannon cmbranno...@gmail.com wrote: Pierre Chapuis catw...@archlinux.us writes: There are things like that (think NDIS - it's Microsoft, but it's a step in the right direction), just not enough , but I think it's a question of time. And then there's the UDI (universal driver interface) (UDI), which Stallman doesn't like. I can certainly see arguments for both sides of that issue. As an aside, I interviewed for a job with MS last year. At some point, the device driver issue was discussed. One of my interviewers made the comment that a universal driver interface would be a bad thing, because it reduces competition. I don't think that they like commoditized things at all. Was that a private joke or something ? :) The only thing MS has ever done or tried to do is killing competition. And who writes drivers ? Isn't it / shouldn't it be the hardware makers who designed the hardware in the first place ? And most of them probably invest 99% of the resources for Windows, and 1% for all the other os. Well it probably depends a lot on the hardware/drivers we talk about, so it is probably difficult to stay general. And to be honest, I probably don't have a good picture of it. But it just sounds like a funny argument to me.
Re: [arch-general] kernel26 in [current] cries for love when new kernel version hits [testing]
On Tue, Dec 15, 2009 at 11:26 AM, Emmanuel Benisty benist...@gmail.com wrote: Funny thing is, as stated in my first post, I'm using Arch stock kernel on only 1 machine out of 4. All of them using [testing] by the way. I'm not the bad guy saying Arch is obliged to do this or that, I just noticed this to be a quite common situation and I still do not think it's the way to go. I do not think Tobias or Thomas will be influenced by this (they may never ever read this thread actually :P ) but that doesn't stop me to voice my opinion on this matter. So better file a feature request.
