Re: [arch-general] Keyboard (special funcs) in Gnome3
On Wed 24 Oct 2012 09:31 -0300, Héctor Herrera wrote: Well, I have installed the package you suggested, but sadly I still don't control the volume with my multimedia keys. And I dunno what to do. I assume that I'll have to configure by my hand in /usr/include/X11, isn't it? For the record, I'm using an HP g4 1271-la notebook Oh, and anyway, thanks for the responses! Does ~./xbindkeysrc not work? That's what I do. However, not in Gnome. Example: mpc toggle XF86AudioPlay mpc stop XF86AudioStop mpc next XF86AudioNext mpc prev XF86AudioPrev
Re: [arch-general] [arch-dev-public] testing/systemd 191-1 failed to boot
On Sat 22 Sep 2012 15:06 +0200, Thomas Bächler wrote: Am 22.09.2012 10:07, schrieb Heiko Baums: Am Sat, 22 Sep 2012 15:09:02 +0900 schrieb Zhengyu Xu xzy3...@gmail.com: After updating systemd to 191-1 in testing repo, I had following messages during booting and the process was stuck (crashed). [ 10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8 error 4 in libc-2.16.so[b752a000+1a4000] [ 10.539700] systemd[1]: Caught SEGV, core dump failed. Downgrade to 189-4 can solve this problem. I want to know if this is a personal problem or a general bug affecting others as well. Why am I not surprised? Yes, binary init system is so much better than a script based init system. And Poetterix is so damn good, so advanced, such an evolution and so much better than the common and over 40 years well tested sysvinit. Come on systemd fanboys, here you have the first example. There's more to come. I'll get my popcorn. After the recent outbreaks, we have been discussing banning people from arch-general. At the time, the people we talked about had calmed down and everything went back to normal, so there was no point in going forward with it. However, your name just made top of the list. If I see you interrupting one more technical discussion with trolls and flames, you will be banned indefinitely without further notice. I will not see another one week flamewar on this list. You are a grown man (at least you look like one), so you should know that this kind of post adds nothing to the discussion, but starts yet another flamewar. Start acting like a grown man and keep it to yourself, unless you have something to say that's worth saying. I am completely against banning people, but at this point, it is either banning people or shutting down this list entirely. I would petition that he be fully banned from all arch lists, forum, irc, etc.
Re: [arch-general] Country Name (ISO-3116) Issues
On Mon 02 Jul 2012 19:28 +1200, Jason Ryan wrote: On 02/07/12 at 07:20am, Zero Cho wrote: Thanks for your support. You're right. This is not intended to be a political debate, so I have been using a neutral word, Taiwan, rather than other more official but sensitive, less common name. It's the fact that ISO is not reflecting how most of the world see it. ISO does not have authority over the country name. ISO does not obligate to reflect how world sees things too. I'm not asking for special treatments. I'm just asking you to follow the convention created from previous experience to prevent the misunderstanding and debates. As the ISO page clearly states, the country names are sourced from the United Nations: “The country names in ISO 3166 come from United Nations sources. New names and codes are added automatically when the United Nations publishes new names in either the Terminology Bulletin Country Names or in the Country and Region Codes for Statistical Use maintained by the United Nations Statistics Divisions.” http://www.iso.org/iso/country_codes/country_codes Asking Arch to modify the standard *is* a political act. The whole point of using a standard for what is an extremely fraught topic (geography and naming conventions) is to avoid these sorts of issues. If you have an alternative standard that can be used, please suggest it. An alternative has already been suggested. There's no reason we need to keep coming back to ISO/UN. I'm not sure what the issue is anymore and why this can't be fixed. This is silly. At any rate someone should write to whoever maintains django-countries and have them fix things on their end. These things could have been mentioned from the very get-go in the original bug report in discussion instead of closing the report with zero discussion. Incidentally the forum post is now closed and hidden from the public. Great work.
Re: [arch-general] Country Name (ISO-3116) Issues
On Sun 01 Jul 2012 23:08 +0800, Zero, Chien-An Cho wrote: Hello, First of all, I am sorry to bring political issues to here. I have been using ArchLinux for years, deployed on many servers, though I'm not joining the community until now. The recent changes to the ArchLinux webpages (ex. Downloads, Mirror Status) is really offending Taiwanese people. I would like to bring up this issue, and preferably to resolve this issue. I have posted this message on the forum: https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator suggested me to post on arch-general, so here it is. :) There is also a bug tracking issue submitted by other Taiwanese user that I'm requesting for reopen here: https://bugs.archlinux.org/task/30444 The following text is the same as the post on forum, except a few modification to make text smoother. The recent changes on the download page named Taiwan as Taiwan, Province of China, which is not reflecting the truth that Taiwan is a independent country which having its own government. I think this might be caused by following the ISO-3166 country name list standard. However, I don't think ISO-3166 is a good list when it comes to the country name. Many open source communities have encountered this problem before. Most of them understand that ISO-3166 is not really a neutral list that we all hope for, and thus made switch to a separate maintained country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big commercial entities also opt not to use Taiwan, PRC in their country list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et cetra. A possible solution might be using the country name list from ICU[6]. I believed the ArchLinux is trying to expand its user-base around the world, so a neutral country name list would be the best for the benefit of all of us, ArchLinux developers and users. As a Taiwanese ArchLinux user, I'm really happy to see that user base of ArchLinux is growing in Taiwan. Some educational institutions provide mirrors site in Taiwan, Wiki localized in Traditional Chinese in the recent years. I sincerely hope this issue can be resolved as soon as possible. Let's keep the issue simple and not flaming it, thanks. References: [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672 [2] Rails: http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/ [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html [4] Apple: http://www.apple.com/choose-your-country/ [5] IBM: http://www.ibm.com/planetwide/select/selector.html [6] ICU: http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt I agree. I'm very disappointed by the response of Dave Reisner on that bug report. The reality is that the PRC does not have jurisdiction or claim over Taiwan. When standards are false they should not be followed. Dave: Can you educate yourself a little about the Republic of China and Taiwan vs the People's Republic of China, before making a final decision? Thank you.
Re: [arch-general] Country Name (ISO-3116) Issues
On Sun 01 Jul 2012 21:23 +0200, Tom Gundersen wrote: On Sun, Jul 1, 2012 at 7:28 PM, Loui Chang louipc@gmail.com wrote: On Sun 01 Jul 2012 23:08 +0800, Zero, Chien-An Cho wrote: Hello, First of all, I am sorry to bring political issues to here. I have been using ArchLinux for years, deployed on many servers, though I'm not joining the community until now. The recent changes to the ArchLinux webpages (ex. Downloads, Mirror Status) is really offending Taiwanese people. I would like to bring up this issue, and preferably to resolve this issue. I have posted this message on the forum: https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator suggested me to post on arch-general, so here it is. :) There is also a bug tracking issue submitted by other Taiwanese user that I'm requesting for reopen here: https://bugs.archlinux.org/task/30444 The following text is the same as the post on forum, except a few modification to make text smoother. The recent changes on the download page named Taiwan as Taiwan, Province of China, which is not reflecting the truth that Taiwan is a independent country which having its own government. I think this might be caused by following the ISO-3166 country name list standard. However, I don't think ISO-3166 is a good list when it comes to the country name. Many open source communities have encountered this problem before. Most of them understand that ISO-3166 is not really a neutral list that we all hope for, and thus made switch to a separate maintained country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big commercial entities also opt not to use Taiwan, PRC in their country list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et cetra. A possible solution might be using the country name list from ICU[6]. I believed the ArchLinux is trying to expand its user-base around the world, so a neutral country name list would be the best for the benefit of all of us, ArchLinux developers and users. As a Taiwanese ArchLinux user, I'm really happy to see that user base of ArchLinux is growing in Taiwan. Some educational institutions provide mirrors site in Taiwan, Wiki localized in Traditional Chinese in the recent years. I sincerely hope this issue can be resolved as soon as possible. Let's keep the issue simple and not flaming it, thanks. References: [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672 [2] Rails: http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/ [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html [4] Apple: http://www.apple.com/choose-your-country/ [5] IBM: http://www.ibm.com/planetwide/select/selector.html [6] ICU: http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt I agree. I'm very disappointed by the response of Dave Reisner on that bug report. The reality is that the PRC does not have jurisdiction or claim over Taiwan. When standards are false they should not be followed. Dave: Can you educate yourself a little about the Republic of China and Taiwan vs the People's Republic of China, before making a final decision? Thank you. This has been discussed a number of times. While no one has so far questioned the validity of the bug, the consensus seems to be that this should be taken upstream [0]. I hope it is clear that no offense is intended, and that we do not want to make any political judgments (and hence defer to the UN). [0]: http://www.iso.org/iso/updates_on_iso_3166.html. Gimme a break. These kind of political issues aren't solved by taking it upstream. Since when are politicians or people under the influence of politics known for their outstanding adherence to logic and reason? It's not such a simple technical thing that you can take it upstream. If you have any idea how the ISO works you will wake up to the fact of how ridiculous that suggestion is. If Taiwan (ROC) can't get it to happen, what do you expect of us? But as has been suggested maybe Arch should choose a different upstream for this kind of information. Please open your mind a little, a false standard is no standard at all.
Re: [arch-general] NAS drive revisited
On Sun 20 May 2012 21:58 +0100, P .NIKOLIC wrote: I am still not able to write to my external NAS drive an iomega home media drive You just can't write? If you can mount but can't write, then you have the wrong permissions on the drive and/or uid/gid mixups, depending on how you want it set up. So lets approach it from a different angle we will say i have not done anything yet just plugged it into the network What packages am i looking to install and what configuration changes do i need to make . See the Arch wiki. The ball's in your court here. What you read depends on how you want to access the drive. SMB? NFS? I am trying this way round as i am chasing my tail up somewhere dark and nasty right now . I know the drive works perfectly i have just tried it with an old Suse distro on the Laptop and instant read/write no problem now if it can work on there why wont it work on Arch .. Your description of the problem is much too vague. If you want help, you ought to describe more specifically what you're trying to do, and what is going wrong.
Re: [arch-general] problem with pulseaudio when resuming from pm-suspend
On Fri 09 Mar 2012 11:45 +, Tom Gundersen wrote: On Fri, Mar 9, 2012 at 10:27 AM, XeCycle xecy...@gmail.com wrote: I use pulseaudio on my laptop. I start it by `start-pulseaudio-x11` in something like .xinitrc (I use a standalone wm with lxdm). When I resume from pm-suspend, the system beeper issues several beeps; when I open a urxvt, a bash completion failure will issue a beep too. However when any program that talks to pulseaudio starts (or try again to talk to it), e.g. start pavucontrol, everything is normal again. My guess is that what happens is that pulseaudio blocks the sound device, and that's the reason you don't hear the beep when it is running (i.e. when sounds play). Disabling PA as Ralf suggests would in this case not help at all, and likely just make it worse (I wish people would stop suggesting to disable PA regardless of what the problem is, in most cases this is not going to make things easier). I'm confused. Why is pulseaudio so necessary? I just use alsa for sound and have no problems whatsoever. Granted, I don't use one of them fancy shmancy desktop environments.
Re: [arch-general] Automatic File Associations Alloting
On Mon 21 Nov 2011 22:36 +0100, Philipp Überbacher wrote: Excerpts from Bernardo Barros's message of 2011-11-20 00:06:05 +0100: text files opening automatically with wine is really a VERY annoying thing... This is pretty clearly a DE issue. Are you all using the same DE or is this common behavior in all popular DEs? I rarely have any of those issues since I usually call my programs by name and ROX uses manual file association. Only firefox is sometimes hard to convince, but it uses gconf or some other DE stuff underneath. It's somewhat nice to see that DE users also have problems with that kind of stuff. Maybe this stuff can be changed using regedit or however that great program to change gconf settings is called. I'm sorry, somehow this ended up as another DE flame instead of being helpful. Oh well... So how is this stuff controlled these days? Those funky desktop files? gconf? dconf? Something else entirely? I'm thinking that this (the culprit) should be removed from all install scriptlets: update-desktop-database -q It's caused me headaches too. And I don't use any DE.
Re: [arch-general] system slowing down when copying files.
On Sat 27 Aug 2011 09:12 +0530, Madhurya Kakati wrote: Hi, My system tends to slow down a lot when I copy files to and from a pen drive or even from one hard disk to another. Even my mouse cursor slows down. The system becomes almost unusable. I more than enough RAM and I am using a tiling window manager. So I am not even using a lot of RAM. Why is this happening? I can't work on my system if I run any large file copy/move operation. Please help. Thanks. Your hard drive might be dying. Back up your files now.
Re: [arch-general] replacement for clyde
On Fri 19 Aug 2011 10:43 -0500, Thomas Dziedzic wrote: 2011/8/19 Cédric Girard girard.ced...@gmail.com: On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic gos...@gmail.com wrote: I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua I understand this may seems convenient to some. For me it is just useless and just abstract things from the user. Definitely a valid opinion, as abstraction might be convenient or inexpedience to different audiences, which is why there really isn't a right answer. Programming also has this quality. The problem that I've seen is that some users start treating yaourt as THE package manager and start making bug reports, when the bug exists in yaourt rather than pacman.
Re: [arch-general] [arch-dev-public] dropping tcp_wrapper support
On Sat 16 Jul 2011 15:47 -0500, Peggy Wilkins wrote:
On Sat, Jul 16, 2011 at 3:23 PM, Ionut Biru ib...@archlinux.org wrote:
On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
The annoucement suggests that a major reason for dropping support is
that it is confusing to end users. An easy solution to that is to
make a default hosts.allow file that says ALL : ALL : ALLOW out of
the box. Then those of use wanting to simply restrict access (useful
in many scenarios) can change that default as needed.
i read the news entry couples of times and I don't get it how you
reach this conclusion. Really, this is not the reason and I found
your comment hilarious.
I was referring to this:
Additionally, newer daemons and applications are inconsistent in
their support for libwrap, leading to confusion as to whether an
application supports the library.
This is true, it is confusing. My response was to say, well, change
the default config then, and that criticism won't carry the same
impact. (To be honest I have no idea what Arch's default config is
for /etc/hosts.{allow|deny} because I edit it within minutes of a new
install, but it seems that if it were default allow for ALL then it
wouldn't cause as much trouble for people who wonder why sshd or
whatever isn't working...)
users who want this feature can as well recompile the desire services with
this support.
I will again say I chose Arch because I don't have to spend my time
doing that (for a desktop OS); I very much appreciate the people who
put the time into compiling things so I don't have to. I spend a fair
amount of time compiling software at work, and I don't want a larger
list of things to recompile regularly.
I am not intending on continuing to bore everyone with my opinion here...
I still wish support would stay, but it's not my decision, I just
wanted to speak up in case anyone but me cared (and apparently I
really am the only one...).
I think it makes sense to have only one place to control traffic, makes
things a little simpler. tcp_wrappers is like a helper program for
beginner users to control traffic, but you can most likely find a
program that would help beginners to create iptable rules. I don't use
them so I can't advocate any particular program though.
Cheers.
Re: [arch-general] netcfg 2.6 release
On Sun 19 Jun 2011 23:23 +0200, Rémy Oudompheng wrote: netcfg 2.6 has been released and pushed in [testing]. - /etc/conf.d/netcfg is a new configuration file, currently only used by net-auto-wireless: it is used to configure the name of the wireless interface you want to use (also possible in /etc/rc.conf, but discouraged), and to configure a list of preferred networks you want wpa_actiond to manage (FS#23169) Should the syntax for this documented in the package somewhere?
Re: [arch-general] netcfg 2.6 release
On Mon 20 Jun 2011 03:34 +0200, Rémy Oudompheng wrote: On 2011/6/20 Loui Chang louipc@gmail.com wrote: On Sun 19 Jun 2011 23:23 +0200, Rémy Oudompheng wrote: netcfg 2.6 has been released and pushed in [testing]. - /etc/conf.d/netcfg is a new configuration file, currently only used by net-auto-wireless: it is used to configure the name of the wireless interface you want to use (also possible in /etc/rc.conf, but discouraged), and to configure a list of preferred networks you want wpa_actiond to manage (FS#23169) Should the syntax for this documented in the package somewhere? I try to keep the docs/ syntax as updated as possible. Are there official webpages for projects? other than projects.archlinux.org? There's a page for pacman [1], but I don't know if there's any specific infrastructure for project pages. You will probably have to ask the admins for a space to put pages. [1] http://www.archlinux.org/pacman/
Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)
On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
Ionut Biru wrote:
drop nonfree stuff, fix headers
Modified: PKGBUILD
===
--- PKGBUILD2011-05-07 11:29:11 UTC (rev 122937)
+++ PKGBUILD2011-05-07 11:51:04 UTC (rev 122938)
@@ -5,26 +5,28 @@
-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264'
'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger'
'libvpx' 'libva' 'openjpeg')
+depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264'
'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger'
'libvpx' 'libva' 'openjpeg')
---enable-libfaac \
---enable-nonfree \
Is faac support in ffmpeg causing trouble to other applications or was
changed for licensing reasons?
licensing. if you need faac you should use abs to recompile it
Gah. All this licensing stuff is starting to get really annoying.
Did Arch receive a patent license violation notice or something?
What is Arch's official policies when it comes to patents?
It could have some widespread implications for the distro.
Or the distro could purchase or otherwise aquire licenses to all claimed
patents... ha... ha...
Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)
On Sat 07 May 2011 18:18 +0200, Pierre Schmitz wrote: On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote: On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote: On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote: Is faac support in ffmpeg causing trouble to other applications or was changed for licensing reasons? licensing. if you need faac you should use abs to recompile it Gah. All this licensing stuff is starting to get really annoying. Did Arch receive a patent license violation notice or something? What is Arch's official policies when it comes to patents? It could have some widespread implications for the distro. Or the distro could purchase or otherwise aquire licenses to all claimed patents... ha... ha... Licenses and patents are different things. Some stuff cannot legally distributed and we respect that. This is usually proprietary/non-free software or packages like the Microsoft fonts. (Wasn't there also some mplayer codec pack that included some Windows dlls?) On the other hand there are software patents valid in some countries which apply also to a completely free implementation. This means there are a bunch of packages which you are not allowed to use in the US for example even though they are licensed under e.g. the GPL. Ah yeah I'm making some assumptions. It would be nice to understand the exact reasons that the support was removed. I'm assuming that faac support was removed because of patent issues, and that ffmpeg does conform to the MPEG-2 NBC/MPEG-4 Audio standards. The license of the code itself [1] would not seem to necessarily forbid binary distribution. The reason that it is incompatible with LGPL is because the original license allows free license only to products which conform to the MPEG-2 NBC/MPEG-4 Audio standards. Relicensing all of the code as LGPL would nullify that requirement which is not allowed. [1] http://faac.cvs.sourceforge.net/viewvc/faac/faac/README?revision=1.7
Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)
On Sat 07 May 2011 11:24 -0500, C Anthony Risinger wrote: a bit of a divergence ... but as i think about next-gen packaging quite a bit i've often considered if a most advanced distribution system would negate issues like this ... for example, what if a nonfree package _knew_ it was nonfree, and therefore would only be distributed from servers in countries that do not deem it an issue? when user went to to sync it, their IP would be geolocated (or just a setting, eg. RESIDENT) and if need be the user would be warned that the package they are synced may have unknown legal implications. would something like that work? Maybe not completely. At least it would relieve mirrors of possible infringement which is good for them. Arch might still be found guilty though.
Re: [arch-general] [arch-dev-public] [signoff] initscripts-2011.04.1-2
On Fri 29 Apr 2011 23:00 +0200, Tom Gundersen wrote: On Fri, Apr 29, 2011 at 8:41 PM, David Rosenstrauch dar...@darose.net wrote: Can someone pls clarify what exactly is broken about localtime? I've been using it for years without any (noticable) issue. I'll be happy to switch over if I need to, but I'd like to understand the problem(s) first. There are some implementational problems and some conceptual ones. Please have a look at the link I gave to the systemd page for a brief description as well as http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html for the very interested. Sounds like a hardware problem then. Maybe the bios should tell the OS if the clock is in localtime or UTC. ;)
Re: [arch-general] Printer driver
On Thu 28 Apr 2011 22:50 +0200, Maciej Sobkowski wrote: I want to install driver for my Brother DCP-J315W printer. I've downloaded driver files from brother's site, since there is no package, neither in repo nor in aur. It was in deb format, also rpm available. The driver is split into two packages: dcpj315wlpr and dcpj315wcupswrapper. I converted them to tar.gz archive with deb2targz, extracted and I don't know where to put the files to get the driver working. Hierarchy in cupswrapper: /usr/local/Brother/Printer/dcpj315w/cupswrapper/, and there are brcupsconfpt1 brdcpj315w.ppd cupswrapperdcpj315w files. In lpr there is /usr/local/Brother/Printer/dcpj315w/lpd/ where are brdcpj315wfilter filterdcpj315w psconvertij2, and /usr/local/Brother/Printer/dcpj315w/inf/ where are brdcpj315wfunc brio08ba.bcm brio08bc.bcm brio08bf.bcm brio08bk.bcm paperinfij2 brdcpj315wrcbrio08bb.bcm brio08be.bcm brio08bg.bcm ImagingArea setupPrintcapij I would recommend using the rpm because there is only one extraction step. Also you don't need any special tools to convert or extract rpms or debs. makepkg will automatically extract those archives via bsdtar (part of libarchive). I would move /usr/local/Brother stuff to /usr/share/Brother You might have to edit some of those scripts and wrappers with sed to get the proper paths. If you're using cups you need to remember to add your printer to the cups server for it to work. Please see this wiki page for some tips: https://wiki.archlinux.org/index.php/Creating_packages_for_Brother_drivers
Re: [arch-general] Change Arch's default crond
On Thu 21 Apr 2011 10:46 +0200, Lukas Fleischer wrote: On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote: So what's the status here? I pulled cronie into [community-testing] a couple of days ago and will probably merge it into [community] soon. So that's the one I vote. But regardless of which one we choose in my opinion the sooner we get rid of dcron the better. --Kaiting. I don't want to be pedantic, but what's the point of that? Moving arbitrary cron daemons that no one uses to [community] is nonsense (according to the TU guidelines, you shouldn't even have moved it without prior discussion and consensus on aur-general at all - but as I said before, I don't want to be pedantic here...) This is supposed to be a rule, not just a guideline. The rule doesn't exactly apply to [community-testing]. Perhaps it should? https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_Packages_Entering_the_.5Bcommunity.5D_Repo
Re: [arch-general] [arch-dev-public] [signoff] ncurses-5.8-1
On Sun 27 Feb 2011 12:01 -0600, Dan McGee wrote: On Sat, Feb 26, 2011 at 7:55 PM, Allan McRae al...@archlinux.org wrote: On 27/02/11 10:40, Allan McRae wrote: Major upstream update. Test well. There is no soname bump, but experience tells me that some rebuilds will probably be required to fix minor issues. I have rebuilt community/stfl to fix a crash (used by newsbeuter). I will start a TODO list to keep track of packages that require moved with ncurses. If you do any rebuilds, please add the package to the list. $ tig tig: Failed to create status window I added it to the list (but didn't rebuild it). Rebuild won't do it. tig wants to create zero sized windows which newwin() doesn't allow anymore. We could patch it with some arbitrary size which kind of works, but I emailed the developer to ask how he would deal with it.
Re: [arch-general] [arch-dev-public] Vi package
On Wed 09 Feb 2011 11:23 -0500, Stéphane Gaudreault wrote: Hi, I was looking at FS#20778 and was wondering what we should do with it. While it is true that the traditional vi is buggy and not user friendly. It does not seems that BusyBox is a good alternative. There are options here: 1) Statu quo Pro : * Support for multi-byte character encodings like UTF-8 * Small size Cons : * Did I said that it is buggy ? * Use of this old software in the installer may give a strange impression to new users as they are faced with an editor from the '70 on a distro where everything is up to date. * Appears to be no longer be updated upstream. Opinions? I'd say stick with the status quo. I don't find anything too wrong with the traditional vi. There's the file size and line length limit and those aren't really that bad. The wide terminal issue has been worked around by changing the config header. If you want to do heavy editing other programs are more appropriate in our modern age. Vi is more appropriate for light editing like when doing installation or configuration. Are other bugs that you mention documented somewhere? I'm interested in learning about them. If you can use vim you probably should be able to use vi without too much difficulty. I guess you could argue that having two basic editors (vi and nano) is unnecessary, vi is usually expected to be on a basic system, and nano just bugs me. :D
Re: [arch-general] Rail Model font for coders
On Sat 22 Jan 2011 06:23 -0500, hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com wrote: Can someone stop him from spamming our inboxes ? Meeku: our means the whole mailing list. You should have used the word my and if you are a closet racist by condemning me from participating on this open mailing list then it does not do Arch Linux's reputation any good. Well I refrained from saying anything until now. I'll be honest. I found your original mail to be a bit obnoxious and a bit spammish. I have nothing against your race or religion, but I think your email address is ridiculous. If you want to spread your message, at least put it in an email signature for God/Allah/Yaweh/Buddha/Guanyin/Vishnu's sake. Also the Arch mailing lists are not a place for religious preaching or discussion. Thanks for participating. Namaste.
Re: [arch-general] unable to install anything via yaourt
On Sun 02 Jan 2011 08:00 +0530, Madhurya Kakati wrote: On Sun, Jan 2, 2011 at 7:53 AM, jesse jaara jesse.ja...@gmail.com wrote: Does xz work alone? On 2.1.2011 4.21, Madhurya Kakati mkakati2...@gmail.com wrote: i ran pacman -Syu and system is fully updated. On Sun, Jan 2, 2011 at 7:42 AM, jesse jaara jesse.ja...@gmail.com wrote: Your pacman or libarchive is outofdate or you dont have xz installed when i run the command xz in terminal it prints out the same error. Best to ask the yaourt folks directly via their channels. http://archlinux.fr/yaourt-en
Re: [arch-general] unable to install anything via yaourt
On Sun 02 Jan 2011 08:12 +0530, Madhurya Kakati wrote: On Sun, Jan 2, 2011 at 8:09 AM, Loui Chang louipc@gmail.com wrote: On Sun 02 Jan 2011 08:00 +0530, Madhurya Kakati wrote: On Sun, Jan 2, 2011 at 7:53 AM, jesse jaara jesse.ja...@gmail.com wrote: Does xz work alone? On 2.1.2011 4.21, Madhurya Kakati mkakati2...@gmail.com wrote: i ran pacman -Syu and system is fully updated. On Sun, Jan 2, 2011 at 7:42 AM, jesse jaara jesse.ja...@gmail.com wrote: Your pacman or libarchive is outofdate or you dont have xz installed when i run the command xz in terminal it prints out the same error. Best to ask the yaourt folks directly via their channels. http://archlinux.fr/yaourt-en no. its not a problem of yaourt anymore guys. I have realized that I can't install anything from aur. If you're having problems using yaourt to try to install from [unsupported], or any repo, then you're probably having a problem with yaourt, not the repos. The AUR itself seems to be operating generally fine right now. So, best to ask the yaourt folks for some advice, since they know that program the best.
Re: [arch-general] unable to install anything via yaourt
On Sun 02 Jan 2011 04:51 +0100, Heiko Baums wrote: Am Sat, 1 Jan 2011 22:17:11 -0500 schrieb Loui Chang louipc@gmail.com: If you're having problems using yaourt to try to install from [unsupported], or any repo, then you're probably having a problem with yaourt, not the repos. The AUR itself seems to be operating generally fine right now. So, best to ask the yaourt folks for some advice, since they know that program the best. But he wrote that he gets the same error also if he executes xz directly in a terminal without yaourt and if he installs AUR packages manually with makepkg. So this is probably not yaourt related. Aaah Crap hah. My bad. I guess I'm having trouble reading today. It's been a long couple of days hehe.
Re: [arch-general] We want to help
On Tue 14 Dec 2010 09:54 -0200, Tomás Acauan Schertel wrote: The Brazilian Arch Linux Community wants to help Arch Linux project, working on bug reports and feature requests. As first task, we plan to help conclude the development of AUR version 2. We don't have lots of developers, but we really want to help. And maybe others join us on this effort. To accomplish this, we need to enlighten some points: 1 - where should we look for feature requests? * bugs.archlinux.org? * AUR2 wiki page? 2 - what code repository should we take as start point? * git://gitorious.org/aur2/aur2.git -- the central repository with the stable branch * git://github.com/sebnow/aur2.git -- Xilon's repository * git://ius.student.utwente.nl/aur2 -- Thralas's repository * git://git.berlios.de/aur2 -- Djszapi's repository * git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked repo with some patches and translation's. 3 - How Feature Requests / Bug Reports will be closed on flyspray? * Maybe a TU can do the job. Maybe things get easier if just one (maybe two) TU`s leads us on work. Well, the AUR2 is a completely independent project. I don't think that it should be tracked on the bugtracker for the current AUR - that's unless the Trusted Users decide to adopt it instead of the current codebase. So the answer to question 1 would be the wiki page. 2. I believe you should follow the central repo if you decide to develop on AUR2. 3. I think it's best if AUR2 had a separate tracker. Finally, I'd like to honestly say I don't see AUR2 as really being a worthwhile investment for the next generation of the AUR. It's just another web app like the current AUR, it might have a couple extra frills, but I don't think it makes sense to rewrite the whole thing just for that sake. They can probably added easily enough to the current code. As I see it I agree totally with Anthony's vision of what the future of the AUR should look like. I've actually thought about this for a few years, but I lack the talent to start any implementation. I'm not sure if we will be able to jump right into it though. It might take a couple of generations of the system. A first step would be to take the interface out of the server and have the client deal with that. I think you should take a look at Eli Janssen's AUR json daemon. https://github.com/cactus/spew and C Anthony Risinger's aur-pyjs https://github.com/extofme/aur-pyjs Cheers.
Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
On Tue 07 Dec 2010 20:12 +0100, Heiko Baums wrote: Am Tue, 7 Dec 2010 19:12:05 +0100 schrieb Tobias Powalowski t.p...@gmx.de: This is a proper solution without making core a big monster again. greetings Adding all filesystem tools to [core] won't make it a big monster. ;-) I'm not so sure about that. There are probably more filesystems than I can imagine. I wouldn't be too thrilled if all of that was in core.
Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
On Tue 07 Dec 2010 18:30 +0100, Heiko Baums wrote: Am Tue, 07 Dec 2010 16:26:00 +0100 schrieb Pierre Schmitz pie...@archlinux.de: I second this. If the reason for moving a package to core is that the installer cannot handle it otherwise the installer needs to be fixed. The question is not that the installer can't handle it if it's not in [core]. The question is that if the installer creates a filesystem on the harddisk the appropriate tools need to be installed on the system, too. And this is only possible if those packages are in [core] because the core iso only contains the [core] repo and not [extra] and [community]. Also the netinstall iso can only install from [core] as far as I know. So if AIF supports nilfs or another filesystem, those tools have to be moved to [core]. That's why I would vote against moving it to core. I'd even say we should have a look at those packages in core with low usage and see if we should move them to extra. There are already packages for which we don't get any sign-offs which shows that those are no longer needed to be in core. That's definitely not the definition of [core]. [core] is not for supporting the most used and most popular packages. [core] is for providing system relevant packages which are necessary to build a minimal system. And it's not the dev's task to decide how a user wants to partition and format his harddisk. If it's done like you're suggesting than you would force a user to only format his harddisk with e.g. ext4, because you think that ext4 is the one and only and most popular filesystem and every other filesystem has to be moved to [extra], because they are not necessary or not as popular as ext4. It's all about choice - the user's, not the dev's choice. Man this stuff is hard to read. Anyways, I would like to consider the installer as something separate from the core system. Sure it can help you install the core system, and any extras you may want. That shouldn't mean that the core needs to conform to what the installer enables you to do. Instead every filesystem - probably except for dosfsutils - has to be moved to [core] and be supported by AIF, because a filesystem is the most basic and necessary part of a system which has to be chosen, used and installed during installation. You simply can't reformat or repartition a harddisk after the installation. Well, it's possible but not without having a second harddisk onto which the installed system had first to be copied. But that's not the way a system should be installed. Bull. So every filesystem - regardless of how much it is used and how popular it is - has definitely to be moved to [core] and supported by AIF. And, no, ext2 is not the only filesystem which can be used for /boot and /. But on the other hand every filesystem related package has to be removed from (base), while AIF should then be able to recognize which filesystems are created on the harddisk and install the appropriate filesystem tools automagically. The idea of core was to provide a minimal set of packages that are needed by nearly all users to set up a base system. Our sign-off procedure ensures that we don't put broken packages by accident there. But filesystems - all of them - belong to the very minimal set of packages that are needed to set up a base system. But every user needs a different filesystem for a reason, because every user has different requirements. experimental != broken Just because a filesystem is marked as experimental doesn't mean that it's broken. Btrfs e.g. is missing a fsck, yet, but it shall be pretty stable until the harddisk gets too cluttered. At least it's said by many people in the web. So there are several people who like to use and to test it. As soon as there's a first stable version of a package it should of course not be updated anymore to newer, unstable versions. Of course, those experimental packages should explicitly be marked as experimental in AIF. There have been, btw., several kernel modules in the vanilla kernel which have been marked as experimental for many years even if they haven been really stable in the meantime. So the word experimental is quite relative. I don't think that nilfs matches the criteria needed for inclusion in core. (side note: it has 1.38% usage according to pkgstats) Why does it only have 1.38% usage? Just because it's not in [core] and not supported by AIF, just because a filesystem is usually chose at install time. And poppycock. Ask Microsoft to support every filesystem in existence on their standard install CD and core system and maybe us poor Archers with our limited time and budget can also rise to your stratospheric expectations.
Re: [arch-general] Python 3 Rationale?
On Mon 06 Dec 2010 10:27 -0700, Steve Holmes wrote: Scroll CLEAR down to the bottom for my response. On Wed, Oct 20, 2010 at 12:02:27PM -0400, Matthew Gyurgyik wrote: Really please, please don't top post. http://www.river.com/users/share/etiquette/ Who cares! it takes too long to scroll down through the past fifteen generations to get to the relevant part of the message. Well, it takes me one keystroke. Get a better mail client.
Re: [arch-general] Changing subject line - Was: Python 3 Rationale?
On Mon 06 Dec 2010 23:24 -0500, Kaiting Chen wrote: On Mon, Dec 6, 2010 at 9:12 PM, Allan McRae al...@archlinux.org wrote: Top posting vs. going off topic without changing subject lines. I'm not sure which is worse... Bottom posting in Gmail is a pain in the ass. --Kaiting. Get a better mail client.
Re: [arch-general] what happened to nut (network-ups-tools)?
On Mon 29 Nov 2010 20:03 -0600, David C. Rankin wrote: Where did nut go? I just checked and network-ups-tools is no longer available. Did it change names? I must have missed it. Thanks. David, is it really that hard to do a few searches before asking?
Re: [arch-general] what happened to nut (network-ups-tools)?
On Mon 29 Nov 2010 22:31 -0600, David C. Rankin wrote: On 11/29/2010 09:11 PM, Loui Chang wrote: David, is it really that hard to do a few searches before asking? No, I did search for the package on the web-site. I just didn't think to search AUR. I hadn't heard of packages getting kicked out of the package list before, so it never occurred to me to look in AUR. I'd like to encourage you to perform several searches in different places before asking any question on the mailing list. Ideally, such trivial questions should never be asked on the list. There's a really handy search engine called google (http://google.com) that has phenomenal indexing and will actually help you search multiple sites at once (Arch Linux packages, the AUR, forums, mailing lists, upstream, etc) There may be other search engines as well, but that's the one I've found to be most useful. Cheers.
Re: [arch-general] [arch-dev-public] [extra] repository cleanup
On Sat 13 Nov 2010 15:23 +0100, Heiko Baums wrote: Am Sat, 13 Nov 2010 14:46:30 +0100 schrieb Andrea Scarpino and...@archlinux.org: On Thursday 11 November 2010 22:54:36 Roman Kyrylych wrote: I adopted some (and edited the page). Nice, today we have 291 orphans packages in [extra] (they were 352 three days ago). 62 will be moved to [community]. 127 to AUR. I didn't expect this success. I can start moving them today if you agree. Nice, then I would need to install 110 packages from AUR and compile them manually. When I switched to Arch Linux about 3 years ago it was less than 50. When will the so called binary distribution Arch Linux become a second Gentoo, a pure source based distribution, because no developer is interested in maintaining anything anymore? Btw., PKGBUILDs also in AUR need to be maintained. Really sad this progress and this massive and pointless cleanup. You really should reconsider this cleanup. You should consider that such a distribution - and Arch Linux isn't a small and unimportant distro anymore - is not only about some personal preferences of the developers. Developers of such a binary distro should also maintain packages which they are not using themselves. Sorry, Heiko. I don't think you properly understand Arch culture here. If you want something done you are expected to contribute and put forth your own effort to make it happen. The TUs and Devs cannot be expected to be your personal support team and maintain hundreds of packages that you're particularly interested in unless you're willing to compensate them for their time. Their time is much more valuable than that. Just like your time is too valuable to do it yourself. I'd rather maintainers be forthcoming and allow users to maintain packages that they can't properly support rather than carrying a burden that may be harmful or stressful. I wouldn't say anything if you would cleanup the official repos from unnecessary, unimportant and unused or hardly used packages like some ttf fonts, GTK1 themes, etc. But there are too many, too important packages in your list which definitely belong into the official binary repos and which are in the official binary repos of every other binary distribution. Arch is not just 'another binary distro'. It's a distro for those who contribute. If other people can benefit from that work - that's great! Cheers
Re: [arch-general] Replace dcron once again?
On Fri 12 Nov 2010 10:26 +0900, Alex Matviychuk wrote: Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this: This is from a Linux From Scratch readme here: http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt Nice. The guy who wrote that article is an Archer and former TU. It's also from 7 years ago. I'm sure a good deal has changed since. From my naive point of view, it seems like dcron is more in line with the Arch Way. In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code. My vote would be to focus efforts on fixing the bug and to keep Arch as small and lightweight as possible at its base. One of the best parts of Arch for me is that it starts out minimalistic and you can extend it to make it fit your needs. Trying to make our favorite packages defaults instead of minimal, stable, small packages, is a mistake imho. The only problem is finding someone who can do the work to maintain dcron. It's pretty damning to have a scheduler that can't schedule properly installed by default - that's what people seem to be concerned about mostly. I'd like to keep the simpler package too, but if it ain't working chuck it.
Re: [arch-general] Te agregué como amigo en Faceboo k
On Mon 27 Sep 2010 22:12 +0100, Mauro Santos wrote: This is a message that will probably show up at least one more time because facebook will remind everyone that didn't create an account that they have been invited. Well, I followed the opt out links. Hopefully that works.
Re: [arch-general] Singapore Citizen Mr. Teo En Ming (Zhang Enming) wants to become the next person after U.S. Senator Ernie Chambers to sue God
On Wed 22 Sep 2010 23:18 -0600, Gary Wright wrote:
,.-'...``~.,
.,.-...-.,
.,/...:,
.,?..,
.../...,}
./..,:`^`..}
.../...,:./
..?.__.:`.../
./__.(.~-,_..,:`../
.../(_~,_~,_,:`_/
..{.._$;_..=,_...-,_...,.-~-,},.~;/}
...((.*~_...=-._..;,,./`/../
...,,,___.`~,..~.,`.}../
(`=-,,...`(..;_,,-
/.`~,..`-./
.`~.*-,.|,./.,__
,,_..}.-._...|..`=~-,
.`=~-,__..`,.
...`=~-,,.,...
`:,,...`..__
.`=-,...,%`--==``
_..._,-%...`
...,
Yes Captain Picard.
Re: [arch-general] Adobe Releases New 64-bit Flash Plugin For Linux
On Thu 16 Sep 2010 16:53 +0200, Linus Eklöf wrote: What's kind of sad is that people support and use adobes flash. Gnash might not work that well, but at least you'll kind of show support for free software. What's really sad is that so many sites rely on flash in the first place.
Re: [arch-general] [arch-dev-public] inkscape finding a maintainer
On Mon 30 Aug 2010 19:24 +0200, Gaetan Bisson wrote: [2010-08-30 19:54:44 +0300] Ionuț Bîru: Does anyone in our dev team uses inkscape like a daily bases and wants to maintain it? I use it about once a week or so; if you want inkscape to stay in [extra] I could maintain it. Now if Laurent wants it, I'm also happy to have it go to [community]. Hey... Did we gain some new developers that went unannounced?
Re: [arch-general] 3 minutes and 12 seconds Youtube video of My Arch Linux
On Sun 29 Aug 2010 18:03 +0600, reflexing wrote: On Sun, Aug 29, 2010 at 5:56 PM, Mr. Teo En Ming (Zhang Enming) of Singapore enming...@lavabit.com wrote: I have just uploaded a Youtube video of my Arch Linux which was installed on an external 2.5 USB harddrive December last year (2009). The length of the video is only 3 mins and 12 secs. My Arch Linux is essentially a Linux from Scratch (LFS) 6.5 which I have compiled and installed from scratch, following the LFS 6.5 Handbook very closely. After finishing the basic LFS 6.5 installation, I have installed the pacman package manager from Arch Linux, essentially making the LFS 6.5 installation an Arch Linux installation. With the pacman package manager in place, I was able to install the X.org X Windowing Server and the GNOME Desktop Environment with ease. Please check out my Youtube video at the following link: http://www.youtube.com/watch?v=If9TifbQVmQ At the time of this writing, there are 23 uploaded videos in my Youtube account. You're fucking sick, please stop sending your shit to this list. Hey don't be so mean. This is the first remotely relevant thing he's sent to the list. Seems like he's trying to do better. Heheh.
Re: [arch-general] Referencing $srcdir in PKGBUILD?
On Tue 17 Aug 2010 12:09 +0200, Heiko Baums wrote: Am Tue, 17 Aug 2010 19:15:34 +1000 schrieb Allan McRae al...@archlinux.org: grep your files in your package for $srcdir (the actual value...). If it is not in a config file or RPATH or the like, you can probably ignore it. I'm not quite sure if this is not a bug in makepkg, because I have this problem with almost all of my packages in AUR since the latest update to pacman 3.4.0. I never got this message before and I haven't changed such elementary parts of the packages. And if I'm right this problem appears with almost every package which I install from AUR. But I need to watch it more narrowly. You'll get that with any package that contains debugging symbols.
Re: [arch-general] Referencing $srcdir in PKGBUILD?
On Tue 17 Aug 2010 13:01 +0200, Philipp Überbacher wrote:
Excerpts from Loui Chang's message of 2010-08-17 12:35:41 +0200:
On Tue 17 Aug 2010 12:09 +0200, Heiko Baums wrote:
Am Tue, 17 Aug 2010 19:15:34 +1000
schrieb Allan McRae al...@archlinux.org:
grep your files in your package for $srcdir (the actual value...).
If it is not in a config file or RPATH or the like, you can probably
ignore it.
I'm not quite sure if this is not a bug in makepkg, because I
have this problem with almost all of my packages in AUR since the latest
update to pacman 3.4.0. I never got this message before and I haven't
changed such elementary parts of the packages. And if I'm right this
problem appears with almost every package which I install from AUR.
But I need to watch it more narrowly.
You'll get that with any package that contains debugging symbols.
So it isn't about the usual 'cd $srcdir/${pkgname}-${pkgver}' ?
No, it's about build directories being referenced in the finished
package, not the PKGBUILD.
Re: [arch-general] /etc/profile PATH variable wrong
On Sun 15 Aug 2010 06:33 -0700, mike rosset wrote: I use ~/.local/bin for user specific applications and scripts. ~/bin would create visible clutter to the home folder. -- Ape Lauri Niskanen That might work for you however in Jude's case being a blind user I would think he would want something that is very visible in a braille terminal. Either way I'm sure he can find something that works for him. But this also derails from the topic of /usr/local which is still a valid point. Someone unaware of dotfiles might miss them, but others (blind or sighted) should be able to access them without issue.
Re: [arch-general] /etc/profile PATH variable wrong
On Sun 15 Aug 2010 07:08 -0700, mike rosset wrote:
Someone unaware of dotfiles might miss them, but others (blind or
sighted) should be able to access them without issue.
And all of this has nothing to do with the orignal issue /usr/local. I
only suggested using something in $HOME for user based scripts which
can be anything it does not matter.
It only serves to deflect from why is /usr/local/{bin,sbin} not part
of the default search PATH? when its a FHS standard and has always
been used for custom system wide installs? Obviously a competent
system administrator can add this. However does this mean we should
remove /usr/bin now to? since any competent admin can add that also.
Haha. Don't be so aggressive against discussion on an issue that you
brought up in the first place. We're just trying to help put things in
their proper place. But yeah I agree there are too many silly tangents
on this issue. So let somebody submit a patch and get it over with.
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Sat 07 Aug 2010 20:04 -0600, Gary Wright wrote: On Sat, Aug 7, 2010 at 3:31 PM, Loui Chang louipc@gmail.com wrote: On Sat 07 Aug 2010 01:26 +0200, Guus Snijders wrote: HTH, HAND What? HTH[1] HAND[2] [1] http://www.acronymfinder.com/HtH.html [2] http://www.acronymfinder.com/HAND.html Bah thanks. Bloody Hell. Can we not write in English? I think that sort of thing is more appropriate on AOL chat.
Re: [arch-general] script to reformat 'pacman -Ss' output into 2 readable columns (prevents blindness)
On Thu 05 Aug 2010 22:51 -0500, David C. Rankin wrote: Guys, You got a script for the gals too? :D I developed a script to help me read the output of pacman -Ss in 2 nicely formatted columns. The output of 'pacman -Ss srchterm' drives me nuts trying to read down the package names and descriptions with all the tab indented and wrapped text -- so I fixed it. Download the script here: http://www.3111skyline.com/dl/Archlinux/scripts/srch2list.sh or with the '-d' option for semi-doublespace: This should definitely be the default. Otherwise I may go walleyed. The script needs 1 input. That is a filename 'srchfile' that contains the output from 'pacman -Ss srchterm srchfile' There are 2 options, '-h or --help' gives a brief description and '-d' which causes the output to be essentially double-spaced. (each package description remains single spaced if it requires multiple lines, but a blank line is included between package descriptions) On the todo list is having the script take the input from stdin and eliminate the srchfile. Cheers.
Re: [arch-general] makepkg patch - generate .SRCINFO file when running --source
On Tue 27 Jul 2010 15:25 +0200, vlad wrote: Here is a patch against makepkg from git which introduces a new function write_srcinfo(). This generates a file .SRCINFO - like the .PKGINFO one - when makepkg --source is run and then it is added to the src.tar.gz archive. I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive. .SRCINFO looks like (generated for gcc from core): Nice. :D This is something that I had been brainstorming too. You should submit it to the pacman-dev list and/or the pacman bug tracker.
Re: [arch-general] makepkg patch - generate .SRCINFO file when running --source
On Mon 02 Aug 2010 17:03 +0200, vlad wrote: On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote: On Tue 27 Jul 2010 15:25 +0200, vlad wrote: Here is a patch against makepkg from git which introduces a new function write_srcinfo(). This generates a file .SRCINFO - like the .PKGINFO one - when makepkg --source is run and then it is added to the src.tar.gz archive. I think having such a file is an important step for getting split packages to the AUR. It is also useful for third party applications. Since this file is generated during making the source archive, there is no need for parsing/sourcing the PKGBUILD everytime meta infos are needed afterwards. This is also a way of standardizing the source archive. .SRCINFO looks like (generated for gcc from core): Nice. :D This is something that I had been brainstorming too. Hehe, that's why I did it. I wanted to give this a push. You should submit it to the pacman-dev list and/or the pacman bug tracker. Is pacman-dev public or open for non-devs? Yes. It's open to anybody. Just subscribe first.
Re: [arch-general] mandriva beat us to a new version
On Thu 29 Jul 2010 10:05 -0400, Caleb Cushing wrote: of perl http://jquelin.blogspot.com/2010/07/perls-state-in-mandriva-cooker.html how embarrassing. Congrats to them! How's that embarrassing?
Re: [arch-general] perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote: This is what happens to me now # pacman -Syu ... :: Starting full system upgrade... warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1) I guess this happens because I have installed something from testing at one point, and anyway, I know how to override this warningm but.. The question is, should pacman think that 2.1401 is newer than 2.15 ? I would hope so. 1401 15
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :) Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks Cheers!
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote: On Jul 17, 2010, at 11:42 AM, Loui Chang louipc@gmail.com wrote: On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote: Oh, I do. I would just prefer to work with the package management framework, not work around it. I think this is something that hooks could do. It's a feature that's in brainstorming. Maybe you could help implement it. http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks As a heads up, this (kernel rollbacks) is a planned feature of the mkinitcpio-btrfs hook in AUR. It will be implemented in one or more of about three ways: https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395 You must be using btrfs for / of course. So, that's not something that would work within the package management framework, is it?
Re: [arch-general] Bashification of initscripts for moderate speedup
On Wed 30 Jun 2010 18:48 +0200, Philipp Überbacher wrote: Excerpts from Aaron Griffin's message of 2010-06-30 17:55:40 +0200: On Wed, Jun 30, 2010 at 10:00 AM, Caleb Cushing xenoterrac...@gmail.com wrote: On Tue, Jun 29, 2010 at 1:57 PM, Aaron Griffin aaronmgrif...@gmail.com wrote: I have no idea where the number came from, but both 80 and 132 are standard column widths used for normal and wide terminals. should be 78 columns I do believe that's the standard for kernel/git it allows for email comments more easily apparently. No, physical terminals went to 80 columns. The 78 number was likely related to editor chrome, such as line numbering... I'm not sure of the details. I believe email typically has 78 width due to the fact that is expected for replies. I also read about 72, and it's my current setting for vim when editing mails, but I have no idea where that comes from... Yeah I generally use 72 for emails.
Re: [arch-general] Bashification of initscripts for moderate speedup
On Tue 29 Jun 2010 09:27 -0500, Dan McGee wrote: Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style Neat. Where does the 132 columns come from?
Re: [arch-general] Licensing of Arch Wiki content
On Wed 30 Jun 2010 00:15 +0100, Ananda Samaddar wrote: On Tue, 29 Jun 2010 17:56:39 -0500 Aaron Griffin aaronmgrif...@gmail.com wrote: I was also waiting for someone more knowledgeable with regards to the wiki. If it's my say-so you want, I don't see a problem with adding *additional* content under CC. But switching all *existing* content to CC might be a problem. Not really, I'm wanting to adapt a Gentoo document to Arch's needs. This document is CC by SA attribution licensed. The whole Wiki article would have to be under the same license and not the GFDL. The CC and GFDL licenses are not compatible. Would it be ok to add a footer paragraph to the Wiki article stating that the WHOLE article is CC licensed and to disregard the GFDL footer at the bottom? This would only be for new Wiki articles. I am not proposing re-licensing existing Wiki articles. Just do it.
Re: [arch-general] Bashification of initscripts for moderate speedup
On Mon 28 Jun 2010 08:04 -0500, Dan McGee wrote: On Mon, Jun 28, 2010 at 7:42 AM, Caleb Cushing xenoterrac...@gmail.com wrote: On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther victor.lowt...@gmail.com wrote: Questions, comments, flames, etc. welcome. why go this way instead of the other? (clarification why go deeper into bash instead of trying to posix-ify the scripts) Because we are never going to eliminate arrays from rc.conf. Well, it may still be beneficial to some. The scripts could be used with a different style rc.conf in other environments.
Re: [arch-general] Bashification of initscripts for moderate speedup
On Mon 28 Jun 2010 09:13 -0500, Victor Lowther wrote: On Jun 28, 2010, at 8:59 AM, Loui Chang louipc@gmail.com wrote: On Mon 28 Jun 2010 08:04 -0500, Dan McGee wrote: On Mon, Jun 28, 2010 at 7:42 AM, Caleb Cushing xenoterrac...@gmail.com wrote: On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther victor.lowt...@gmail.com wrote: Questions, comments, flames, etc. welcome. why go this way instead of the other? (clarification why go deeper into bash instead of trying to posix-ify the scripts) Because we are never going to eliminate arrays from rc.conf. Well, it may still be beneficial to some. The scripts could be used with a different style rc.conf in other environments. Then it will not be Arch. Depends on what you define as Arch. I've heard that Arch is what you make of it. Hehe. I don't know if you could disqualify it from a difference of one file.
Re: [arch-general] Bashification of initscripts for moderate speedup
On Mon 28 Jun 2010 10:03 -0500, Victor Lowther wrote: On Jun 28, 2010, at 9:49 AM, Loui Chang louipc@gmail.com wrote: Depends on what you define as Arch. I've heard that Arch is what you make of it. Hehe. I don't know if you could disqualify it from a difference of one file. For me, part of it is that bash is used pretty ubiquitously as the configuration and scripting language of choice. Changing that to posix sh in one of the main config files would be a big shift. Ah. For me Arch is much more than bash configs or scripts. They could all become POSIX compatible and I'd still see it as Arch. If Arch started to require python, or more I might start to see it differently - it would be harder to maintain a slimmer system.
Re: [arch-general] Boost
On Fri 18 Jun 2010 11:52 +0200, Sven-Hendrik Haase wrote: On 18.06.2010 11:38, Ionuț Bîru wrote: On 06/18/2010 09:30 AM, Allan McRae wrote: On 18/06/10 16:24, Daniel Bumke wrote: Does anyone know what's going on with boost? It seems it was downgraded from 1.42.0 to 1.41.0 a while back, and hasn't been updated to the latest 1.43.0. I was going to build the latest on my machine, but if there's something wrong with it I might hold off or go with the older version. I know there was some talk about splitting it up; is that the reason? From memory 1.42 broke encfs. The encfs developers blame boost, the boost developers blame encfs, so nothing was done in recent updates from either side. So we either update boost or break encfs... encfs devs released a new version which works with 1.41. yesterday i built 1.43 but the splitting is holding me back. It has a very annoying build system and until now we have in the bugtracker one which is copying files around from a directory to another. FS#19749 What's the issue here though? We have a working split package and everyone is happy? Bjam is a crappy build system but until CMake is more actively maintained by Boost (last boost-cmake release was 1.41) it'll have to do. Boost is an important part of C++ development, it should not go without update in Arch. Wow, this is kind of depressing. Why would some package in community block an established library from being upgraded in extra?
Re: [arch-general] What should the Arch Security Team be called?
On Thu 17 Jun 2010 21:19 +0100, Dave Morgan wrote: On 17/06/10 at 08:46pm, Ananda Samaddar wrote: On to the first order of business. As the subject says, what should security team be called. Hopefully we can get a few suggestions and then reach a consensus. Arch Linux Security Task Force just sounds like too much of a mouthful to me. I was brooding over this and I thought some sort of acronym that's an actual word would sound better, so I came up with this: 'Arch Response Team for Security' or ARTS. It's a bit cheesy and cheats a bit to get the acronym but is instantly memorable. I'm aware arts was also a KDE technology but it has long since been deprecated. Ideas? Arch Response Security Engineers? HAHA YES!
Re: [arch-general] Licensing of Arch Wiki content
On Thu 17 Jun 2010 21:42 +0100, Ananda Samaddar wrote: I notice it's all under GFDL 1.2. I'm wanting to use a Gentoo doc for the Arch Security stuff but it's under a CC-SA attribution license which is incompatible with GFDL. Would it be possible to allow Wiki content under a CC licenses? I can't see it being too controversial a choice, as in CC licenses are now widely accepted. Even the venerable RMS uses CC licenses for his personal stuff as does a lot of the FSF/GNU stuff. I don't think anyone would sue you for it.
Re: [arch-general] Cannot install shaman from AUR
On Sat 05 Jun 2010 23:05 +0200, Xavier Chantry wrote: On Sat, Jun 5, 2010 at 7:36 AM, xenof0nt xenof...@gmail.com wrote: 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 ? At least it'll never be in core. Good enough for me!
Re: [arch-general] change user and group in env in PKGBUILD
On Thu 03 Jun 2010 01:48 -0400, Caleb Cushing wrote:
so i'm trying to update the oracle pkgbuild on AUR. oracle's installer
won't run as root, but it thinks that it's running as root. how can I
change this? I believe it is supposed to be run as the user and group
that it gets installed as what's the best way to add those in the
pkgbuild?
Try adding a trivial package function:
package() {return 0}
or you might be able to manipulate BUILDENV and add !fakeroot.
Re: [arch-general] Games for Linux !
On Fri 28 May 2010 23:00 +0530, Madhurya Kakati wrote: This mailing list is only for discussing problems. Besides we use arch-games repo ;) On 5/28/10, Nilesh Govindarajan li...@itech7.com wrote: It seems there are lot of games for Linux we're not aware of because most of the times we stick to our distribution's repository. I remembered mario that I used to play on console about 8 years ago, so a Google search revealed megamario. All who wish to play games for entertainment check this - http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/ This should suffice for normal gamers. For hard core gamers, it won't. I don't think there's anything wrong with discussing games. But the top posting is.
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
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 about how to deal with people, but he's too stubborn to take any advice.
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
On Thu 27 May 2010 18:32 +0200, Joerg Schilling wrote: Loui Chang louipc@gmail.com wrote: 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 about I am not sure whether you realized that cdrtools is well maintained and without known bugs. Sorry I wasn't completely clear, by maintaining I meant maintaining the binary Arch Linux package. No one is interested in it, and you really can't force interest.
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
On Thu 27 May 2010 19:11 +0200, Thomas Bächler wrote: Am 27.05.2010 17:52, schrieb Loui Chang: 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 about how to deal with people, but he's too stubborn to take any advice. When has that happened? I would gladly package cdrtools. I know from many users that it is superior to cdrkit (although I never had any trouble with either of them). However, I fear that some of my fellow developers would stop me from doing that due to the questionable license situation. http://mailman.archlinux.org/pipermail/arch-general/2010-January/010357.html http://mailman.archlinux.org/pipermail/arch-general/2010-May/013557.html
Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line
On Thu 27 May 2010 14:41 -0500, C Anthony Risinger wrote: On Thu, May 27, 2010 at 2:29 PM, Loui Chang louipc@gmail.com wrote: http://mailman.archlinux.org/pipermail/arch-general/2010-January/010357.html http://mailman.archlinux.org/pipermail/arch-general/2010-May/013557.html eh? more circles? What the hell do circles have to do with anything? The first link seems to show there's no problem with the license. The second link states: And the license of cdrtools is not even the reason that cdrtools is not packaged in Arch.
Re: [arch-general] dualboot?
On Thu 27 May 2010 16:42 -0400, David Rosenstrauch wrote: On 05/27/2010 04:21 PM, Stefan Husmann wrote: python is no requirement for Arch Linux itself. If you do not like it, just do not install it. Isn't pacman written in python? That would make python a requirement for Arch then, right? No, it's written in C.
Re: [arch-general] cdrtools again... yay!
On Wed 26 May 2010 21:59 +0530, Piyush P Kurur wrote: On Wed, May 26, 2010 at 10:06:36AM -0500, Aaron Griffin wrote: On Wed, May 26, 2010 at 9:41 AM, Allan McRae al...@archlinux.org wrote: I do not speak for the other Arch developers, but the reason why I will not officially package cdrtools for Arch is you. My impression of you is that you are very, very annoying and irritating. If there was a bug report made about the cdrtools package in Arch, then I would have to deal with you. I do not particularly want to do that, so I will not package cdrtools. I have heard similar opinions expressed by developers from various other distributions while at Linux meetings, so I am not alone here, even though I might be the only one blunt enough to say it directly. I agree. Deficient upstream is a completely valid reason for excluding things. i.e. Ion3 I like this thread. Burning CD on command line looks like a long ``burning'' issue. Ba dum, ting!
Re: [arch-general] PKGBUILD parser
On Mon 10 May 2010 09:23 +1000, Allan McRae wrote:
On 10/05/10 02:06, Loui Chang wrote:
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
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.
No problem. I didn't really share this before because I hadn't even
thought of a real solution. Since it was mentioned though, I thought I'd
share my thoughts. There are definitely many barriers to sort out.
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.
Yeah there'd have to be some kind of standard constructs for all these
kinds of hacks like platform specific dependencies, etc. That would
probably mean changing or expanding the PKGBUILD spec. I wouldn't be
afraid to do that, but it might not sit well with compatibility or with
Arch principles.
The joy of PKGBUILDs is that they are so flexible. The problem with
PKGBUILDs is that they are so flexible.
Indeed.
Re: [arch-general] PKGBUILD parser
On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote: 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... 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
Re: [arch-general] Err... Why is gvim now conflicting with vim?
On Fri 07 May 2010 10:01 -0500, Burlynn Corlew Jr wrote: On Fri, May 7, 2010 at 9:57 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 05/07/2010 09:48 AM, Burlynn Corlew Jr wrote: On Fri, May 7, 2010 at 4:04 AM, Johannes Held m...@hehejo.de wrote: http://www.archlinux.org/news/495/ * If you have gvim installed, the update will inform you that vim conflicts with gvim. This is the expected behavior. Installation of vim and gvim separately is no longer required, the gvim package now installs vim as well. This is a rolling release, not an LTS. There is no excuse to not be updating regularly and reading the news. If its a production machine and you are worried about breakage maybe you shouldnt be running arch on it. The ML, forums, and irc are full of people who refuse to read the news or update regularly, and we all waste time answering questions that with proper arch maintenance would ensure that they never come up. It's people like you that give arch a bad reputation. Grow up. Saying you were wrong would be the more mature avenue. I did not bash or call names, I stated the obvious. This is not the first time the ML has been posted with your obvious questions. Yeah. If you notice something odd on your system please take the time to read the news before asking a question. If you have some more time maybe check the forum and wiki as well. Cheers.
Re: [arch-general] about arch
On Thu 06 May 2010 18:08 +0900, Juan Diego Tascón wrote: I was reading the about page (http://www.archlinux.org/about/) in the archlinux website and I noticed that this line is a little outdated: Arch also offers an [unsupported] section in the Arch Linux User Repository (AUR), which contains over 9,000 build scripts It should say over 21.000 build scripts. WHAT?! NINE THOUSAND?!
Re: [arch-general] Raising identical task against multiple packages?
On Sat 24 Apr 2010 11:06 +0100, Magnus Therning wrote: Is there a way to raise an identical task against multiple packages in FlySpray? I'd like to raise a task against all binary haskell-* packages, but I'd rather like to avoid wearing out my mouse doing it ;-) Open one task and list all the packages in the details.
Re: [arch-general] Raising identical task against multiple packages?
On Sat 24 Apr 2010 20:21 +0100, Magnus Therning wrote: On 24/04/10 15:47, Loui Chang wrote: On Sat 24 Apr 2010 11:06 +0100, Magnus Therning wrote: Is there a way to raise an identical task against multiple packages in FlySpray? I'd like to raise a task against all binary haskell-* packages, but I'd rather like to avoid wearing out my mouse doing it ;-) Open one task and list all the packages in the details. Is that just a suggestion from you, or the official Arch way of doing it? The reason I'm asking is that I just don't see how raising a single task would make sure that it gets done. There are more than one maintainer of the haskell-* packages in [extra] and [community]. Who would the task be assigned to? I don't know if there's any 'official' way to do it, but other tasks with multiple packages have been handled like this, and this is the most logical way to handle it if you give it a moment's thought. Assign it to everyone that maintains a haskell-* package.
Re: [arch-general] what is this supposed to mean ?
On Wed 21 Apr 2010 23:49 +0200, Matěj Týč wrote: On Thu, 2010-04-22 at 00:28 +0300, Evangelos Foutras wrote: Please see the front page news. There are instructions regarding the CUPS update. :) And I also think that it is not feasible to have to take a look at the frontpage if you upgrade like once a month, but the package creator can include a message in the PKGBUILD itself, so it doesn't seem to be a pacman flaw. Yeah it would be nice if the warnings and notes could be included in the pacman sync database somehow. Tying those messages directly to the packages makes a lot of sense to me. As far as I know, this isn't currently possible though.
Re: [arch-general] kaffeine [sigh] is there an alternative that:...
On Tue 30 Mar 2010 19:26 +0200, Heiko Baums wrote: 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 don't know what planet you come from, but that seems pretty simple and straightforward to my inferior human brain.
Re: [arch-general] on rolling release / reinstallation
On Wed 17 Mar 2010 16:01 -0400, Joe(theWordy)Philbrook wrote: So I'm guessing that these workarounds happen whenever a pacman -Syu leads to breaking something... (Which means that I probably should only do an pacman -Syu when A) I've got time to test all my stuff. AND B) I've got time to look for a workaround that I hope someone else already figured out...) My question is how often would you recommend doing a pacman -Syu to avoid having so many workarounds that you feel like it might have been easier to reinstall It really depends on what happens during development. I'd say once a month is a good frequency, but always remember to read the announcements on archlinux.org. You can also subscribe to the announcements mailing list: http://mailman.archlinux.org/mailman/listinfo/arch-announce Cheers.
Re: [arch-general] Something really wrong with yum-createrepo from AUR - doesn't work. [Solved - sort of]
On 03/13/2010 01:57 PM, David C. Rankin wrote: The yum-createrepo package seems not to be the same as the createrepo package that you normally see. Specifically executing the yum-createrepo script with the help option discloses: It's better if these things are documented on the package's AUR page.
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 09:34 -0600, Aaron Griffin wrote: Commenting on closed bugs is not doable in Flyspray. More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question That's not always true. There have been instances where I've commented on closed bugs to point at an alternative solution or note where the bug had been fixed where the developer neglected to.
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote: On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. I think another problem is that the bug wranglers aren't necessarily involved in development and don't communicate with the developers before taking action on a bug. That's no fault of the developer, but is a fault with the bug wrangler.
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 14:11 -0600, Aaron Griffin wrote: On Fri, Mar 12, 2010 at 2:12 PM, Loui Chang louipc@gmail.com wrote: On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote: On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. I think another problem is that the bug wranglers aren't necessarily involved in development and don't communicate with the developers before taking action on a bug. That's no fault of the developer, but is a fault with the bug wrangler. Err? This sounds like quite a broad generalization without specific examples. Do *you* have any examples you'd like to share? Sure. On occasion Paul Mattal will close or edit bugs in the AUR bug tracker. He's no longer involved in development and hasn't communicated with me about any of the tickets he touches.
Re: [arch-general] what is the procedure when your find an out-of-date package in AUR?
On Thu 11 Mar 2010 11:50 -0600, Burlynn Corlew Jr wrote: On Thu, Mar 11, 2010 at 11:44 AM, Xavier Chantry chantry.xav...@gmail.comwrote: 2010/3/11 David C. Rankin drankina...@suddenlinkmail.com: 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. 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. Sometimes pasting the pkgbuild in comments is the only solution, especially with lazy maintainers. :/ I've used a share posted that way, and a copy and paste seemed to work fine. Not that it will always work though, I still agree its bad practice, but short of another solution it is necessary at times. Use a pastebin or something instead.
Re: [arch-general] [arch-dev-public] Clean up the base group
On Sun 28 Feb 2010 01:59 +0530, Gaurish Sharma wrote: rp-pppoe should not be removed, Its very handy and easy to use tool. It was using it this tool I was able to connect the internet in ArchLinux. without it I won't be able to install arch. the alternative ppp is hard to configure. Rp-pppoe doesn't need to stay in base to remain in core though. It should be available to install via CD-ROM if it's in core.
Re: [arch-general] How to obtain development headers for package
On Tue 23 Feb 2010 23:11 +, Michishige Kaito wrote: Maybe I'm just not understanding how Arch works, so please forgive my ignorance. I come from ubuntu, and there you get development headers for most packages by following the naming convention, which is package-dev. A quick apt-cache search package | grep dev would yield the right package. Now, I'm trying to obtain these on my fresh arch, but can't seem to find anything through pacman search or google. Anyone could hint me in the right direction? If it's useful, I need the dev headers for sqlite3. The standard practice in Arch is to keep development headers in the package, so they should be included in the sqlite3 package. Contact the package maintainer if anything is missing. Enjoy!
Re: [arch-general] [patch] AIF, discover repos on iso.
On Fri 19 Feb 2010 22:26 +0100, Mark Pustjens wrote: The attached patch fixes a TODO in lib-pacman of aif. Instead of hardcoding that `core' is always available locally and falling back to net for others, it now checks /src/ for repos. It assumes repos are stored at /src/$repo/pkg/. All these repos are added as cache dirs. While preparing pacman, a number of repo names are provided to be prepared. All those repos which were requested are added as actual repo. If this repo is available locally, the url points to disk. Otherwise it falls back to the mirrorlist. Please let me know what you think. Nice. You probably should send that to the arch-releng mailing list.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Mon 25 Jan 2010 16:28 +0100, Joerg Schilling wrote: Heiko Baums wrote: I don't know anything about the technical differences between cdrkit and cdrtools but http://cdrkit.org says: News 2009/10/11 Cdrkit 1.1.10 has been released. So the last stable release was not a year but only three months ago. This looks like an active development for me. Please have a closer look on _what_ was changed in this release. This have been mainly single char typo corrections but the 100 well known bugs that exist as long as the fork exists have never been fixed. On the original software, you see more changes (enhancements and fixes) in a lazy week than the cdrkit project did get since May 6th 2007 in total. In the fork, problems are ignored. In the original software, problems are fixed very soon; typically within hours. This is why there are no known problems in the original software. The fork did not publish a single version that was known to be without bugs at the time of publishing. The original cdrtools project did publish more than 70 releases in the same time and more than 60 of them did have not a single bug when they have been published. Maintainers of packages in Arch Linux may decide to package any software whether it's a fork of an existing package or not. If there are outstanding licensing or legal issues they may decide to avoid that particular software. The issue isn't really about bugs vs. no bugs. So let's stay on topic. It's more about licenses and the legal ramifications that may come with improper usage. I think Arch followed Debian because they seem to know a lot more than we do. On the other hand, maybe we should be using debs rather than .pkg.tar.gz if that's the case. (hah) It is important to respect the caution that the devs are taking. Personally, if it was my decision, I'd encourage any Arch dev or TU who is interested in maintaining cdrtools to go ahead with it. I don't have the same faith in Debian that a lot of others might. Anyways, this package could easily be made available in an unofficial repository until everyone is comfortable with the licensing. Don't rely on the devs to do everything for you.
Re: [arch-general] Quoting of E-mails
On Tue 12 Jan 2010 19:28 +0100, Guus Snijders wrote: On 12-01-10 06:27, Loui Chang wrote: I think part of the problem is that some email clients like gmail webmail help persist the bad behaviour. They default with top posting replies and sending HTML emails. I have requested that they change the defaults, but haven't gotten any response. It isn't a big surprise though. Actually, it /is/ configurable in gmail. It may be configurable, but the defaults persist bad behaviour. They really should be changed.
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon 11 Jan 2010 13:54 -0500, Daenyth Blank wrote: On Mon, Jan 11, 2010 at 13:38, Aaron Griffin aaronmgrif...@gmail.com 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 +1 I appreciate that you've added to the discussion. I hope that we may reach a large sum total. +100 Cheers!
Re: [arch-general] Quoting of E-mails
On Mon 11 Jan 2010 21:33 -0700, Steve Holmes wrote: re-read the old stuff over and over again. Nothing annoys me more than haveing to page through five generations of past messages in a single thread to get all the way to the bottom just to have a single line of text say something like Thank you or I agree or whatever. Fortunately I find that sort of thing isn't too common on the mailing lists. Usually more interesting or useful commentary is added to the discussion. The only thing that makes bottom-posting, like this bareable to me at all is Mutt's 'S' command which takes the cursor down to the unquoted text for much quicker reading. I also find mutt's 'T' helps. It hides the quoted text. If bottom-posting is so passionately desirable, then may I suggest people trim down the history of a thread to the most recent 1 or 2 generations back. Or maybe even better, just reply with no quoting and and briefly summarize the quoted context. Yeah, I realize quoting past context is more work. I just find that when people top-post, I can seem to get through the mud a lot faster. Indeed trimming quotes is part of proper email ettiquette along with bottom posting. Sometimes I think people should pass a quiz before they're allowed to post to the mailing list. I think part of the problem is that some email clients like gmail webmail help persist the bad behaviour. They default with top posting replies and sending HTML emails. I have requested that they change the defaults, but haven't gotten any response. It isn't a big surprise though.
Re: [arch-general] Looks like an AUR (web interface) bug?
On Mon 04 Jan 2010 05:46 +0800, talki walki wrote: The following page of msort in AUR says Package details could not be found. http://aur.archlinux.org/packages.php?ID=33319 While one can fetch the package info using the rpc interface: wget 'http://aur.archlinux.org/rpc.php?type=searcharg=msort' -q -O- Hmm that's very odd. Somehow the CategoryID was set at 0, which has no value in the categories list. I manually changed the ID. The package should appear on the web site now. How did you upload your package?
Re: [arch-general] Good press at distrowatch.com
On Fri 18 Dec 2009 17:54 +0100, Dieter Plaetinck wrote: I agree with Dieter, that the install should be measured by speed and automation -- but long ago I realized that there a whole lot of other people out there that just don't think like me :p Don't misunderstand me. An interactive hold-your-hand-a-bit installation processes is a good thing for many use cases (if implemented correctly). There are many ways to judge installations by. I'm only saying: if one chooses to judge an installation system by the criterion of speed, then (s)he better gets his/her facts right before calling our approach slow[er]. It's probably considered slower because there is a lot of prior knowledge that is required. It may be easier (and faster) for someone who has no computer background to install Ubuntu than to install Arch. With Arch that person would have to do a lot more reading and learning, which would take a lot more time.
Re: [arch-general] Single Person ISP?
On Thu 19 Nov 2009 00:44 -0700, Brendan Long wrote: So recently Verizon has stopped letting me do free tethering and I've been looking for a replacement. Apparently all of the free ISPs I can find all require that you use their shitty Windows program to connect, so I decided, I have a phone line, a modem and an internet connection, maybe I can make my own ISP. There are probably ways around that windows program requirement for the free ISPs. Years ago I was able to connect to AOL using a program called penggy.
Re: [arch-general] Arch Linux Magazine
On Mon 02 Nov 2009 19:26 -0600, Daniel J Griffiths wrote: Loui Chang wrote: Hey guys. I'm just curious. What's going on with the magazine? Is there any intent to revive it? I know that I'd look forward to news/forum summaries at least if there isn't time for all the other stuff. Cheers. I received the above email from Loui on the 31st and have been putting a good deal of thought into the current magazine/newsletter situation. As many of you know, Kensai recently moved and got married and I recently moved and have been trying to find a job. Shortly before receiving this email, Kensai and I had discussed the issue, but we didn't come to any real decisions. Hence, I'm sending my thoughts to the community and letting you in on the discussion. One of the possibilities that was brought up was separating the newsletter and magazine, much as it was when I first started AUM. I do not believe this is a good course of action due to one of the main reasons for the merger: the licensing rights to the Arch name and logo. While the magazine did well on its own, I simply can't afford to maintain the domain and server for it without help from the community, but I can't accept financial contributions for said project as long as it is using Arch branding. On the other hand, leaving it the way it is is proving difficult. I don't know Kensai's current situation, but I'm seeing less and less of him online which makes submission of any completed magazine/newsletter issues difficult as he is the only one with upload rights to the server currently on staff. My situation has settled down enough that I am now able to dedicate the time necessary to continue production of the magazine/newsletter as I used to. In fact, I have a good bit of content ready for the next release, whenever that becomes possible. I would like to see the magazine/newsletter make a comeback to where we were when we left off and then some. I want to see more community contributions, writers, I'd like to get the Schwag report back (Dusty, that's you if you're still up to it), etc. This is a big project that has greatly benefited our community and I hate to see it in it's current state. Please let me know what you all think so that we can expedite the release of another issue! @Kensai: Let me know what your current situation is (I know how being a newlywed is, been there a few times now...), and either way, best of luck (hopefully your luck is better than my first attempt was). My solution would be to give you full news editor permissions making you the defacto editor. If the current editor doesn't come back into the picture then you can officially be declared Boss of the Magazine.
Re: [arch-general] google wave
On Mon 02 Nov 2009 00:06 +0100, f...@kokkinizita.net wrote: On Sun, Nov 01, 2009 at 05:57:34PM -0500, Trav wrote: Sent nomination for both muhammad.a.qa...@gmail.com and francz...@gmail.com! May I suggest to create a Google Group 'please-invite-me-to-google-wave' and then keep this all related stuff off this list. As a new user of ArchLinux I've been a member of this list for only a few days. I posted a question about netcfg and got one informative answer for which I'd like to thank the poster, Thomas. So it seems that despite all the glorious talk about netcfg on the wiki (it can do everything you want, if you have a problem with it it must be you) nobody is using it, or at least able to provide an example of a working wireless setup. For the rest there's been this endless OT chatter of people wanting to be invited to Google Wave. If this is the standard on this group, I will not remain much longer. I agree. It's pretty damned ridiculous. People on this list can't seem to take a hint.
Re: [arch-general] google wave
On Sat 31 Oct 2009 16:40 +0100, bardo wrote: 2009/10/31 Heiko Baums li...@baums-on-web.de: And with Google!? I don't understand how one can be interested in letting Google read and use his/her personal e-mails, documents etc. I'm very careful about my privacy. My google account doesn't usually host private/work e-mails, for those ones I have an account with someone who cares about my privacy (an Italian project, autistici.org). Mails I'm sending from this address are going to become public anyway, so I care more about other features. Have you read their terms of use? And do you know what Google does with your e-mails, documents and other data? Google reads, scans and evaluates e.g. every e-mail which is sent to or from a Gmail account and every document which is edited by Google Docs. I read their terms of use. I'm more aware of the problem than you think, and in fact I'm active in a privacy-related project. And if I *really* need to use gmail for a private message, I encrypt it with GPG. Also, I don't use google docs or similar apps. The only thing from Google I'm using is their search engine and this only without cookies. I won't give Google my personal communication or documents. And I'm thinking about not sending e-mails to Gmail addresses anymore. It should also be noted that, if someone writes you from a gmail address, their communication to you gets logged. This means that there's no way to keep google (or $otherprovider) out of your business. Also, people don't care, because it is in *their* freedom to choose whatever service they prefer. And this is a good thing, even though their choice involves *your* privacy. I suppose that, with a real lot of time, money and good lawyers, you could force google to not read e-mails because their customers agreed to their ToS, but not the people they communicate to. In conclusion, even though I sympathize with your views, I think your battle is lost because it's flawed in its basis. If you don't like how e-mail works, well, there are internationally recognized standards for it, nothing you can do about it. Just change for a different service which is based on technology that doesn't allow the provider to read user's data. After all, there are technologies that allow us to log into services without them or anybody knowing our passwords, why not making it mandatory for contents? We just need a new protocol. And a good reason for users to make the switch, since as we know people are lazy. Keeping emails away from google isn't even a half-measure towards privacy. If you're actually concerned about people accessing your private information, you'll encrypt all your data and transmissions.
Re: [arch-general] google wave
On Sun 01 Nov 2009 00:12 -0200, Hugo Yamashita wrote: Can you send my friend one too? He is also a Arch Linux user, but he is not in this list... hugo.takeo[at]gmail[dot]com Hey can everyone send invite requests directly to the person holding invites rather than to this mailing list? Thanks.
Re: [arch-general] Intel AG 4965
On Fri 16 Oct 2009 06:33 -0300, Alan Hoffmeister wrote: OK, I'll try when I get home... On my work i could connect whit a WEP wireless... Maybe some problem whit the wpa stuff? Att, Alan Nicolas Bigaouette wrote: I would suggest trying some lower level tools, like netcfg or even wpa_supplicant directly, to see if it is the driver or the tool... 2009/10/16 Alan Hoffmeister alan...@gmail.com Tom K wrote: Flavio Costa wrote: Maybe the output of NetworkManager's log would be helpful too. Try # tail -f /var/log/messages while connecting to a wireless connection. On Thu, Oct 15, 2009 at 8:28 PM, Alan Hoffmeister alan...@gmail.com wrote: [...] Try to trim the excessive quoting guys.
Re: [arch-general] X fails to start with intel card after latest kernel update
On Wed 14 Oct 2009 13:45 -0500, David C. Rankin wrote: On Sunday 11 October 2009 03:33:57 am Jan Spakula wrote: Excerpts from David C. Rankin's message of So Okt 11 10:16:57 +0200 2009: On Sunday 11 October 2009 03:10:15 am David C. Rankin wrote: I'm back already. The wiki page must be out of date. It says to put the following in modprobe.conf (which is deprecated): options i915 modeset=1 Now what?? Put it in /etc/modprobe.d/modprobe.conf (that's where I have it). Jan, What about modprobe.conf being deprecated?? /etc/modprobe.conf is deprecated. /etc/modprobe.d/*.conf is used instead.
Re: [arch-general] let's discuss /srv again
On Fri 02 Oct 2009 12:23 +0200, Thomas Bächler wrote: Sergej Pupykin schrieb: Patching them is overkill, it would be an example of the unnecessary patching we do not want in Arch. I would keep them self-contained, no matter which solution will be used in the end. I wouldn't even have such a big problem with having configuration in /usr/share/www/phpmyadmin/config.inc.php or so. In any way, filling /srv with data from pacman is a bad idea, /home and /srv should be user territory only. It is not problem for user, but as I understand it should not be modificable files in /usr/share/ There are many shoulds here: - You should not unnecessarily patch applications. - You should not fill /srv or /home with pacman data - You should not put user-modifiable files in /usr/share The last should is IMO the weakest of all. You can easily avoid violating the first two though. I would say this is the best solution, but it would be great to have some more opinions from other devs and TUs here, maybe even some from our overlord. If you're asking for opinions, I think that the web apps should go into /usr/share/pkgname then the user can then copy the data over to suit their web server set up.
