[arch-general] [pkgstats] Patch to allow pkgstats to submit info through a proxy (if this is setted on http_proxy)
Hi,
I've been trying to submit my stats to the statistics page [1], then I
realized that I wasn't submitting anything (I had pkgstats running on
a cron). Then I decided to find the reason and it's simply I am behing
a noisy and non-transparent proxy (ISA Server which is even worst).
So, I decided to do a little patch to pkgstats, I've tested and now
it's working .. (I am checking if the http_proxy env var is empty and
else I am setting a variable called prox which have the value of the
proxy).
Just that ;), patch attached
[1] https://www.archlinux.de/?page=PackageStatistics
--
Angel Velásquez
angvp @ irc.freenode.net
Arch Linux Trusted User
Linux Counter: #359909
http://www.angvp.com
--- /usr/bin/pkgstats 2009-10-22 15:15:45.0 -0300
+++ pkgstats2009-12-21 11:06:37.0 -0300
@@ -36,8 +36,13 @@
echo arch=$(uname -m)
echo pkgstatsver=${pkgstatsver}
else
+if [ -z ${http_proxy} ]; then
+prox=
+else
+prox=--proxy ${http_proxy}
+fi
echo 'Submitting data...'
- curl ${debug} -f -H 'Expect: ' \
+ curl ${prox} ${debug} -f -H 'Expect: ' \
--data-urlencode packa...@${pkglist} \
--data-urlencode arch=$(uname -m) \
--data-urlencode pkgstatsver=${pkgstatsver} \
Re: [arch-general] A universal Operating System API - why don't we have it?
2009/12/20 Laurie Clark-Michalek bluepepp...@archlinux.us You cannot write an application for windows and expect it to work on Linux. Java? The success of the language is based around the fact that almost every computer has the runtime installed, regardless of operating system. Does that not count as a global API? Laurie I can't resist to quote awarenetwork (http://www.awarenetwork.org/usr/?q=11 ): saying java is good because it runs on all platforms is like saying anal sex is great because it works on all genders :-) Manu
Re: [arch-general] [signoff] kernel 2.6.32.2-1
On Sun, 2009-12-20 at 21:32 +0100, Tobias Powalowski wrote: Hi guys, Upstream changes: http://kernelnewbies.org/LinuxChanges Arch Linux bugfixes/feature requests: http://bugs.archlinux.org/task/16855 # added CONFIG_PM_DEBUG http://bugs.archlinux.org/task/17106 # added CONFIG_MMIOTRACE Arch Linux changes: - splitted kernel-headers to extra package If you want to build external modules please install: pacman -S kernel26-headers Please change your PKGBUILDS to makedepend on this package. - added xen support to 64bit kernel I tested this kernel using xenserver, but the kernel doesn't get loaded, xenserver says: 21/12/2009 13:54:44 Error: Starting VM 'Arch' - Internal error: Failure(Error from xenguesthelper: caught exception: Failure(\\ \Subprocess failure: Failure(\\\xc_dom_linux_build: [2] xc_dom_find_loader: no loader foundn\\\)\\\)) I googled the error, and i found that is because xenserver it's trying to load a non PV-aware kernel btw, the lts kernel boots ok in xenserver. -- Yonathan H. Dossow Acun~a Unidad de Servicios de Computacion e Internet Fono: +56 32 2654367 Universidad Tecnica Federico Santa Maria Valparaiso, Chile
Re: [arch-general] A universal Operating System API - why don't we have it?
On Sun, Dec 20, 2009 at 7:52 AM, Laurie Clark-Michalek bluepepp...@archlinux.us wrote: You cannot write an application for windows and expect it to work on Linux. Java? The success of the language is based around the fact that almost every computer has the runtime installed, regardless of operating system. Does that not count as a global API? Laurie Say whaaat? Java? Girl, don't take it bad, but .. NO, or you want a bloated and crappy OS?. -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-general] A universal Operating System API - why don't we have it?
On Fri, Dec 18, 2009 at 4:24 AM, RedShift redsh...@pandora.be wrote: Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... I look at it this way: an OS is a *tool,* whereas electricity, CDs and such are commodities, and need to be fungible. Tools are *not* fungible; the way you interface with a tool is very tightly coupled with the purpose of that tool, which is why you should never use a hammer to pull a screw. The abstractions OSs (and also programming languages) present represent what they're designed to do, so making a one-size-fits-all tool is worse than useless. The desktop wars and such arguments all commit the fallacy that OSs are a pretty shell over computer hardware, whereas they are (or should be) tools targeted at (more or less) specific solutions. -- Ryan W Sims
Re: [arch-general] [pkgstats] Patch to allow pkgstats to submit info through a proxy (if this is setted on http_proxy)
On Mon, Dec 21, 2009 at 12:39 PM, Pierre Schmitz pie...@archlinux.de wrote: Am Montag 21 Dezember 2009 15:13:53 schrieb Angel Velásquez: So, I decided to do a little patch to pkgstats, I've tested and now it's working .. (I am checking if the http_proxy env var is empty and else I am setting a variable called prox which have the value of the proxy). That shouldn't be needed because curl reads the env vars itself (at least according to its man page) Btw: pkgstats not that usable atm. Well curl wasn't reading the env vars, in fact I had to add this option --proxy. So if curl isn't reading the env vars there is a curl's bug. And why is not usable pkgstats? -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [arch-general] A universal Operating System API - why don't we have it?
2009/12/21 Angel Velásquez an...@archlinux.com.ve: On Sun, Dec 20, 2009 at 7:52 AM, Laurie Clark-Michalek bluepepp...@archlinux.us wrote: You cannot write an application for windows and expect it to work on Linux. Java? The success of the language is based around the fact that almost every computer has the runtime installed, regardless of operating system. Does that not count as a global API? Laurie Say whaaat? Java? Girl, don't take it bad, but .. NO, or you want a bloated and crappy OS?. -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com Hey now, lets chill it a bit, I never said it was good... just universal. And on the anal sex point... actually, I think it'd be better for the convocation as a whole if we dropped that analogy. Laurie
Re: [arch-general] A universal Operating System API - why don't we have it?
Laurie Clark-Michalek bluepepp...@archlinux.us writes: Java? The success of the language is based around the fact that almost every computer has the runtime installed, regardless of operating system. Does that not count as a global API? The concept is called write once, run anywhere. An early example is UCSD Pascal, developed in the late 1970s. UCSD Pascal's P-code is somewhat analogous to JVM bytecode. There were implementations of the P-code interpreter for many early microcomputers. Perhaps UCSD Pascal would have been more popular if it weren't so expensive. IIRC, the IBM PC version was priced at $495. MS-DOS was cheaper. Java may be the most popular example of write once, read anywhere, but it was not the first. -- Chris
Re: [arch-general] A universal Operating System API - why don't we have it?
Le lundi 21 à 18:57, Laurie Clark-Michalek a écrit : And on the anal sex point... actually, I think it'd be better for the convocation as a whole if we dropped that analogy. Is that what they call a Freudian slip? -- Fred
Re: [arch-general] A universal Operating System API - why don't we have it?
2009/12/21 Frédéric Perrin frederic.per...@resel.fr: Le lundi 21 à 18:57, Laurie Clark-Michalek a écrit : And on the anal sex point... actually, I think it'd be better for the convocation as a whole if we dropped that analogy. Is that what they call a Freudian slip? -- Fred I never should have said anything *facepalm* Laurie
[arch-general] Xorg changes / DRM modules
I've updated the git packages for nouveau and ati ddx driver packages in testing. I also updated the nouveau-drm package. This required to add the new nouveau-firmware package. It will be also needed to use kernel nouveau-drm module that will be introduced with kernel 2.6.33. I will keep updating the separate nouveua-drm module for a while to get features and fixes faster than in Linus tree. The firmware will probably also result in loading issues in early kms mode. We might think about recommending late mode for now. libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy
Re: [arch-general] [arch-dev-public] Xorg changes / DRM modules
On Mon, Dec 21, 2009 at 11:35:12PM +0100, Andreas Radke wrote: libdrm has been updated to 2.4.17 - this is breaking all radeon 3d stuff and will require changes in MESA when I understand the upstream devs right. Mesa7.7 is expected in a few days anyways and should make Radeon 3d stuff working again after a few late commits (7.7rc4 doesn't build with new libdrm). Other drivers should still work. Please test them. Radeon kms is still buggy like hell and unusable for my RC410 [Radeon Xpress 200M] card. It makes X and the whole system freeze instantly when moving windows around or when I try to start 3d apps. Sometimes even at Xorg start at all. This has been introduced with 2.6.32 kernels. Upstream recommends to try the various drm trees: http://article.gmane.org/gmane.comp.video.dri.devel/40626 Any opinions from other ati users what branch is the most stable and useful these days? I'm thinking about adding a radeon-drm kernel module package to solve the tons of speed and stability issues. As already written on the closed devel list, I'd like to get help for these packages from other devs and community members. Whoever is well informed in Xorg/kernel drm development and wants to help to stabilize our drivers please contact me. -Andy I'm not an expert but I will share my experience anyway. I follow drm-radeon-testing branch but I think drm-radeon-next is considered more stable for official packaging. Is shipping an updated radeon module enough though? I don't think It will work without all the new drm code. The KMS code is starting to heavily depend on irq which didn't exist when 2..6.32 was released. With newer code you will need the ucode firmware(1). 2.6.32.2 was bugged because of a patch that assumed the existence of irq. IMHO, Encouraging people to dasable KMS on official packages is more sane for now. Those who need the latest and greatest should do it on their own. (1) http://aur.archlinux.org/packages.php?ID=33016
Re: [arch-general] [arch-dev-public] [signoff] nano 2.2.1-1
Am Mon, 21 Dec 2009 23:09:05 +0100 schrieb Andreas Radke a.ra...@arcor.de: note: since 2.2.0 nano failed to open PKGBUILDs for me. after removing old /etc/nanorc and replacing it with the new one it works again. I'm answering to arch-general because I can't write to arch-dev-public. This issue is with the file /usr/share/nano/arch.nanorc. I haven't looked at it but after disabling it nano works again. Greetings, Heiko
[arch-general] Kernel 2.6.32
I was using the testing kernel 2.6.32 without an issue but then when the kernel went to core my system would no longer boot. It would start to boot half way then just go dead. I don't have any error messages to post because the screen went blank. Grub was working fine as far as I can tell. I had to use the Arch live CD to revert kernels back to an earlier version. Has anyone been having issues with the stable kernel 2.6.32? Like I said, 2.6.32 from testing worked fine. Thanks.
Re: [arch-general] Kernel 2.6.32
I do have an ATI card. I'll try that thanks! I did notice that 2.6.32 would boot into a graphical mode shortly after it started booting even though I didn't have one set in my GRUB conf. 2.6.31 didn't do this. Thanks for the help! On Mon, Dec 21, 2009 at 7:05 PM, Ian-Xue Li da.mi.spi...@gmail.com wrote: On Mon, 21 Dec 2009 18:35:30 -0500 Frank Hale frankh...@gmail.com wrote: the kernel went to core my system would no longer boot. It would start to boot half way then just go dead. I don't have any error messages to post because the screen went blank. Grub was working fine as far as I can tell. if you had a ati card with KMS enabled, try to add nomodeset to the kernel line in grub. -- Ian-Xue Li da.mi.spi...@gmail.com
Re: [arch-general] Kernel 2.6.32
Adding nomodeset to my kernel boot line in Grub fixed the problem. Thanks! On Mon, Dec 21, 2009 at 7:29 PM, Frank Hale frankh...@gmail.com wrote: I do have an ATI card. I'll try that thanks! I did notice that 2.6.32 would boot into a graphical mode shortly after it started booting even though I didn't have one set in my GRUB conf. 2.6.31 didn't do this. Thanks for the help! On Mon, Dec 21, 2009 at 7:05 PM, Ian-Xue Li da.mi.spi...@gmail.com wrote: On Mon, 21 Dec 2009 18:35:30 -0500 Frank Hale frankh...@gmail.com wrote: the kernel went to core my system would no longer boot. It would start to boot half way then just go dead. I don't have any error messages to post because the screen went blank. Grub was working fine as far as I can tell. if you had a ati card with KMS enabled, try to add nomodeset to the kernel line in grub. -- Ian-Xue Li da.mi.spi...@gmail.com
