Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Mon, Jun 21, 2010 at 10:53 PM, Dan McGee dpmc...@gmail.com wrote: On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger anth...@extof.me wrote: On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae al...@archlinux.org wrote: On 22/06/10 12:07, C Anthony Risinger wrote: my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual. Then you should probably move along... find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch and these are just the patches named for the security issue they fix. The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable. indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others. alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around. at any rate i don't agree with it but meh, i'm just a worker bee :-) Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer. They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no. hmm, so the fundamental problem is that the word 'upstream' implies a unity that does not exist. at this point i would enter conversation about reconciling individual 'upstreams' to a common backend, such that distributions/contributors/users may immediately benefit from each others work; a p2p application and public software broadcasting framework upon which distributions could be founded... a different topic :-) i suppose... unmaintained should have patches and very small, concise changes to poorly maintained, and maybe even _very_ few to regularly maintained. yet, most security related alerts are for higher profile applications; a more immediate response i would think? i simply don't want to see a collective effort to preempt upstream; i prefer to manually digress from vanilla, and i'm probably a minority. C Anthony
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On 22/06/10 15:59, C Anthony Risinger wrote: On Mon, Jun 21, 2010 at 10:53 PM, Dan McGeedpmc...@gmail.com wrote: On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risingeranth...@extof.me wrote: On Mon, Jun 21, 2010 at 10:16 PM, Allan McRaeal...@archlinux.org wrote: On 22/06/10 12:07, C Anthony Risinger wrote: my point of this ramble if there is one, is that personally, i don't want _anyone_ other than upstream to make security decisions regarding their software.if Arch started naively backporting stuff based of the latest alert from XYZ, i wouldn't be sticking around to long. even if an security hole is found i _don't_ want the fix to be included by default, unless it came from upstream in the form of a new release, which Arch would just pick up as usual. Then you should probably move along... find /var/abs -name *CVE* /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch /var/abs/extra/alpine/CVE-2008-5514.patch /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch /var/abs/core/expat/CVE-2009-3720.patch /var/abs/core/expat/CVE-2009-3560.patch and these are just the patches named for the security issue they fix. The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable. indeed. 2007/8/9? are these patches from years ago, for dead software (xmms?)? i don't know the state of the others. alright, so you're patching stuff... why? why are such old patches not in upstream? if things were done appropriately there wouldn't be a need for intermediary patches because glaring security holes are quickly absorbed into upstream. or... whats the deal here? i don't get the need to carry these around. at any rate i don't agree with it but meh, i'm just a worker bee :-) Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer. They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no. hmm, so the fundamental problem is that the word 'upstream' implies a unity that does not exist. at this point i would enter conversation about reconciling individual 'upstreams' to a common backend, such that distributions/contributors/users may immediately benefit from each others work; a p2p application and public software broadcasting framework upon which distributions could be founded... a different topic :-) i suppose... unmaintained should have patches and very small, concise changes to poorly maintained, and maybe even _very_ few to regularly maintained. yet, most security related alerts are for higher profile applications; a more immediate response i would think? i simply don't want to see a collective effort to preempt upstream; i prefer to manually digress from vanilla, and i'm probably a minority. Not really. We do like vanilla software and aim for that in our repos. But it not an unbreakable rule. What I would like to see one day is a header on all patches detailing where they come from and what they do. Something like in Debian of LFS. Allan
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
2010/6/21 Ng Oon-Ee ngoo...@gmail.com: I'd still like to know how this replaces/conflicts with Arch policy for 'as upstream as possible'. I'm aware that just starting out the answer may just be we don't know yet, but for me one of the benefits of Arch is that all packages are close to upstream (and thus its easy to discuss bugs with upstream, which may not be the case with 5-10 security-patches from git/svn). how 'bout things upstream doesn't take care of like pam.d policies... I seem to recall there being a request for a pam policy for login managers... as a result of my pointing out that even if your shell is false you can login graphically. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
Excerpts from Andres P's message of 2010-06-22 01:53:20 +0200: On Mon, Jun 21, 2010 at 7:17 PM, C Anthony Risinger anth...@extof.me wrote: He said from git/svn... ie backporting, not contributing. ...? Once they're in svn they're confined to abs? Besides, it's not like there's anything keeping upstream from looking at obsd cvs, Debian's bug tracker, nor Arch's svn repo, etc. Andres P Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream, it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it. -- Regards, Philipp -- Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen. Bertolt Brecht, Der gute Mensch von Sezuan
Re: [arch-general] Kudos to the Arch devs!
On 06/22/2010 09:10 AM, Gaurish Sharma wrote: Hi, I would be interested to know your experience of running arch as server os. running I use distros like debian,CentOS etc. till now I have been scared of running arch as server. Please share your experience Regards, Gaurish Sharma Even I've started using arch on the server (the second VPS, of my friend), (you know if you've read my thread limit posts, etc.) Arch makes a perfect distro for server I feel. It doesn't install stuff by default which makes things rock solid. The admin knows what is installed and what not, so troubleshooting is easy in case someone hacks in through a security hole. Also it is damn easy to use those PKGBUILD scripts from AUR to have custom compiled software under the same name, so it won't create the dependency issues. For example phpmyadmin depends on mysql-clients and php, you can have those packages with the same name, or under a custom name with provides=() in the PKGBUILDs of php and mysql. So binaries can be self compiled for optimization and use scripts like pma, python ones, etc. directly from the repos. -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com Cheap and Reliable VPS Hosting: http://j.mp/arHk5e
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Tue, 22 Jun 2010 13:16:23 +1000 Allan McRae al...@archlinux.org wrote: The point is that the developers around here already patch for security issues. The only change that I think that a security team will achieve is to notify me (as a developer) of issues that I have overlooked on the upstream mailing lists and file a bug report. It is a bonus if the issue is pre-analyzed for me and all relevant links supplied so I can assess it quickly myself and release a fixed package if I deem that being suitable. Allan This is exactly what we plan to do, with the addition of providing interim PKGBUILDs (with a disclaimer that they are unofficial) and announcements when a security related bug is fixed by a package update. Such interim PKGBUILDs would be peer-reviewed by the Security Team and submitted with the relevant bug report to aid the package maintainer. I can't see how this is not useful. It will also lighten the workloads of the devs and package maintainers. Ananda signature.asc Description: PGP signature
Re: [arch-general] Kudos to the Arch devs!
On Mon, 21 Jun 2010 18:44:44 -0500 David C. Rankin drankina...@suddenlinkmail.com wrote: Great Job Devs. That brings my total Arch installs to 7, including my 2 primary servers. Arch has nailed what a distro should be and that's something worth jealously guarding against the pressures of change ;-) I can't say that I totally agree with not changing. I still think we need a Security Team and signed packages to be considered secure enough to be deployed as a server OS. I'm working on providing the former, the latter will hopefully be done soon too. Ananda signature.asc Description: PGP signature
Re: [arch-general] Kudos to the Arch devs!
Excerpts from Gaurish Sharma's message of Tue, 22 Jun 2010 09:10 +0530: I would be interested to know your experience of running arch as server os. running I use distros like debian,CentOS etc. till now I have been scared of running arch as server. Please share your experience I'm using one Arch server as a Samba domain controller (3 years) for ~30 workstations (mostly running Windows XP), file server (including server-based Windows applications), SVN server and my second Arch server is used (also for 3 years) as ftp server, http+php server and Flyspray issue tracker. Everything work fine, but I'm doing updates only ones in 2-3 months. Cheers, Sergey
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher hollun...@lavabit.com wrote: Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream, So it's not just take the time to write the fix, you also have to make sure you rebase it every time theres a white space patch. Let upstream know about your repo and then both can work comfortably... You're implying that upstream is too important or what have you. What about the inverse? it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it. Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot. This arch security news group sounds great. Specially if they intend to sit down and code. Andres P
[arch-general] - makepkg now aborts automatically with any errors during packaging
Hello. With such an addition, how do I make a given command not interrupt makepkg? Like command || ignore_errors
Re: [arch-general] - makepkg now aborts automatically with any errors during packaging
On Tuesday 22 June 2010 20:37:45 Evgeny Burmentyev wrote: Hello. With such an addition, how do I make a given command not interrupt makepkg? Like command || ignore_errors || return 0 ? -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux
Re: [arch-general] - makepkg now aborts automatically with any errors during packaging
On Tue, Jun 22, 2010 at 08:40:18PM +0200, Andrea Scarpino wrote: On Tuesday 22 June 2010 20:37:45 Evgeny Burmentyev wrote: Hello. With such an addition, how do I make a given command not interrupt makepkg? Like command || ignore_errors || return 0 ? -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux That's it, thank you.
Re: [arch-general] - makepkg now aborts automatically with any errors during packaging
No no no no no. || return 0 would exit the function with a success if the command fails. You'll want || true On Tue, Jun 22, 2010 at 8:41 PM, Evgeny Burmentyev vir.fo...@gmail.com wrote: On Tue, Jun 22, 2010 at 08:40:18PM +0200, Andrea Scarpino wrote: On Tuesday 22 June 2010 20:37:45 Evgeny Burmentyev wrote: Hello. With such an addition, how do I make a given command not interrupt makepkg? Like command || ignore_errors || return 0 ? -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux That's it, thank you.
Re: [arch-general] - makepkg now aborts automatically with any errors during packaging
On Tuesday 22 June 2010 20:52:59 Jan Steffens wrote: No no no no no. || return 0 would exit the function with a success if the command fails. You'll want || true right, || true is the real 'Ignore' -- Andrea Scarpino - andreascarpino.it KDE Maintainer in Arch Linux
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Tue, Jun 22, 2010 at 10:37 AM, Andres P aep...@gmail.com wrote: On Tue, Jun 22, 2010 at 4:26 AM, Philipp Überbacher hollun...@lavabit.com wrote: Sure, like any dev will be going through every possible bug tracker, repo or ask any possible user to find patches for his app. Don't be ridiculous. If you write a patch that's not distro specific, then it's your job to get it to upstream, So it's not just take the time to write the fix, you also have to make sure you rebase it every time theres a white space patch. Let upstream know about your repo and then both can work comfortably... You're implying that upstream is too important or what have you. What about the inverse? this is just not how it works. yes, you should rebase if your following _their_ project; it's one command, if that (you can setup automatic rebasing when pulling). if you submit patches, you don't need to re-submit unless your patch was affected by subsequent merges. they don't want to follow 17 obscure forks and figure out how to merge the work... really? yes, upstream _is_ more important. if you must have control, publicly fork the work and go from there. it's not helping anyone by providing alternative builds in the same name, confusing users, and annoying authors. it's the only way it could possibly work. The beauty of arch is that the patch you just wrote is most likely against the latest release, and upstream will likely be happy to get it. Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot. then in my opinion they aren't running BIND. why aren't they pushing back to upstream? if they have conflicts in the project's direction: publicly fork the work and go from there. it's only fair to the original authors. lastly, this: This arch security news group sounds great. Specially if they intend to sit down and code. plus: On Tue, Jun 22, 2010 at 8:37 AM, Ananda Samaddar ana...@samaddar.co.uk wrote: .. with the addition of providing interim PKGBUILDs .. is precisely what i _don't_ want to see happening, at all, bad bad bad. if you want to code, spectacular, learn the app, write code, and submit to upstream. i just am having a hard time believing that you are not only going to track down holes, but have the competence to properly fix them, for all the reasons i've already specified. this is nothing personal, i just flat out don't trust you :-) or a handful of volunteers, and would prefer you limit yourselves to more productive/practical actions like alerts, guides, and communicating with upstream. the overwhelming majority of security holes are not from holes in applications, but holes in deployment methods and careless administration. script kiddies will hit your server with a list of known passwords and an assortment of other goodies; _this_ is noteworthy documentation, an Arch Security Beginner's Guide, and annotations to existing guides. the likely-hood of falling prey to a 0-day exploit is far lower. example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago): On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian ingeniw...@gmail.com wrote: .. Everything work fine, but I'm doing updates only ones in 2-3 months. .. what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y... do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly. these 'security repos' work alright for debian and friends because they use a controlled release schedule; there is no guesswork about the state of the system. trying to do the same for Arch is aiming for a rolling release, single-lib moving target; my crystal ball predicts headaches and worse. again, maybe i'm a minority here, but i _don't_ find patching appropriate except in rare occasions where relying on upstream is either not possible or not practical. having said all that, i _do_ think it would be cool to have lots of quality security related docs, an official security RSS feed, and maybe even output from pacman on packages that have outstanding security flags on them. use your energies to spread knowledge, let the pro's handle the nitty gritty. er, IMO :-) C Anthony
[arch-general] Arch Linux
Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Josef Tupag best humidifiers http://thebesthumidifiers.com
Re: [arch-general] Arch Linux
I've been running it on my X61 for a while now. For the most part? I'm way happy. it's pretty fast, and reliable. However, I have had some issues with my wireless card but that's been acting up for years without me being able to figure out what the problem is (in windows and in linux). All in all however i'd say go for it. Of course the speed of the boot and how quickly your system runs really depends on what you install. a bare-bones system will run much faster with one that has gnome thrown on it because gnome is heavier than nothing :P. -Josh On Tue, Jun 22, 2010 at 1:12 PM, Josef Tupag joseftu...@gmail.com wrote: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Josef Tupag best humidifiers http://thebesthumidifiers.com
Re: [arch-general] Arch Linux
On Tue, Jun 22, 2010 at 10:12:30PM +0300, Josef Tupag wrote: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. I'm writing this on an R51. It has seen Suse, Fedora and finally Arch, and it never booted as fast as it does now. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] Arch Linux
Am Tue, 22 Jun 2010 22:12:30 +0300 schrieb Josef Tupag joseftu...@gmail.com: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Josef Tupag best humidifiers http://thebesthumidifiers.com I'm pretty happy with it on my x31. Except for suspend2disk everything works flawlessly and fast.
Re: [arch-general] Arch Linux
On Tue, 22 Jun 2010 22:12:30 +0300, Josef Tupag joseftu...@gmail.com wrote: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Using Arch on my R61 since I bought it, never used anything else on it. Boot is very fast, but since suspend-to-ram works very well (running s2ram -f -a 2), I don't really care about boot time :) Regards, -- Thomas/Schnouki pgpXJAW6u37x0.pgp Description: PGP signature
Re: [arch-general] Arch Linux
Suspend to disk works really well on my X61, maybe it's just the x31 that had issues. -Josh On Tue, Jun 22, 2010 at 2:31 PM, Thomas Jost schno...@schnouki.net wrote: On Tue, 22 Jun 2010 22:12:30 +0300, Josef Tupag joseftu...@gmail.com wrote: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Using Arch on my R61 since I bought it, never used anything else on it. Boot is very fast, but since suspend-to-ram works very well (running s2ram -f -a 2), I don't really care about boot time :) Regards, -- Thomas/Schnouki
[arch-general] makepkg creates symlink to the package file
Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attila sysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? See you, Attila
Re: [arch-general] Arch Linux
Installed Arch on my X500 and it works amazingly well. Pretty fast and I have a lot of features working that I could never get working with OpenSUSE.
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Tue, Jun 22, 2010 at 2:51 PM, C Anthony Risinger anth...@extof.me wrote: Ok, the beauty of openbsd is that they're running a BIND version that's been patched to the point of no recognition. They have confidence in their skills instead of quitting before giving it a shot. then in my opinion they aren't running BIND. why aren't they pushing back to upstream? if they have conflicts in the project's direction: publicly fork the work and go from there. it's only fair to the original authors. It doesn't matter if they're not running BIND. They have a real scenario where they can test functionality. This pipe dream where every package is kept vanilla for the sake of doing so is called stagnation. Tacking on a ls from over there, a pwd from over here, a kernel from elsewhere... isn't going to help anybody develop an OS into refined product. It's going to feel like a confused crossdresser of a system. What's the point of keeping packages completely disintegrated with its surroundings? They run patched gcc, perl, ksh... etc. And they happen to be the most secure widely known bsd. Would that be possible if they catered to this vanilla fetish? No. Granted, these guys probably don't have the know-how that openbsd does, but they gotta start somewhere. What better place than the randomness that is arch? Andres P
Re: [arch-general] Arch Linux
Excerpts from Thomas Jost's message of Tue, 22 Jun 2010 22:31 +0200: On Tue, 22 Jun 2010 22:12:30 +0300, Josef Tupag joseftu...@gmail.com wrote: Has anyone tried Arch Linux on their thinkpad? I just want to know how fast it is. I don't like the long boot that is found in Ubuntu and many other distro. Using Arch on my R61 since I bought it, never used anything else on it. Boot is very fast, but since suspend-to-ram works very well (running s2ram -f -a 2), I don't really care about boot time :) Two years on R61 - everything works well and fast. Sometimes I run even a couple of VMs (in vbox) simultaneously without any sense of lag. Very happy with it. Cheers, Sergey
Re: [arch-general] makepkg creates symlink to the package file
On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -U pkg at the end of the build and that save you typing the whole PKGDEST path. Allan
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On 23/06/10 05:21, C Anthony Risinger wrote: example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago): On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian ingeniw...@gmail.com wrote: .. Everything work fine, but I'm doing updates only ones in 2-3 months. .. what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y... do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly. What a load of crap... Arch developers only support packages that are currently in the repo. Why would the security team do anything else. If a person is not prepared to update their system regularly, or at least when there is a known security issue in the out-of-date packages they are using, then they should be using a different distribution that makes stable snapshot releases. Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive. Finally, this is not going to change the way development works around here. We would still be patching the software for the security bugs. It will just save the developers more time assessing bug as all the necessary information/links will be provided for us in one spot. Allan
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Tue, Jun 22, 2010 at 6:49 PM, Allan McRae al...@archlinux.org wrote: On 23/06/10 05:21, C Anthony Risinger wrote: example: SSH 0-day exploit is released. bang! you crack out your interim PKGBUILD and crack a beer because your safe right? whoops, because this is a production machine (from a message a couple hours ago): On Tue, Jun 22, 2010 at 10:23 AM, Sergey Manucharian ingeniw...@gmail.com wrote: .. Everything work fine, but I'm doing updates only ones in 2-3 months. .. what?? so i have to also upgrade lib XYZ to get this to work? wait, let's just backport to version X... damn! Sandy Squirrel updated a month ago, so she's running version Y... do you see where i'm headed here? are you going to provide fixes for every possible package update that occurred in the last 6 months? lets say your crazy and you auto update your production machines... now your pulling in a _reactionary_ fix that if appropriate will probably be in upstream in less than a week, and they'll have a security related point-release to address it properly. What a load of crap... Arch developers only support packages that are currently in the repo. Why would the security team do anything else. If a person is not prepared to update their system regularly, or at least when there is a known security issue in the out-of-date packages they are using, then they should be using a different distribution that makes stable snapshot releases. Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive. Finally, this is not going to change the way development works around here. We would still be patching the software for the security bugs. It will just save the developers more time assessing bug as all the necessary information/links will be provided for us in one spot. what, did you read that far and give up? dead/non-cooperative/poor upstreams are not the same as healthy, responsive upstreams. and yes, they do get fixed pretty quick; i can't imagine your dead upstream or upstreams that haven't released in years scenario affects too many applications, what, 1%?... and if it does, then they should either be removed completely or we should start following appropriate points in HEAD, because the project is probably obsolete or deprecated, or en route to such. i've seen several other external projects trying to address the fact that Arch moving at breakneck speed, leaving no prisoners, doesn't work too well for a production machines that can't afford to blindly upgrade junk or reboot at any moment. if so, then you have poor change management skills, and probably don't have many clients either. desktop machines? not important. in the end, i'm not particularly concerned with how people expend their energy. i personally think chasing microscopic holes in this or that is a colossal waste of time when the real security issues surround the other 99.9%; deployment. there are more pragmatic ways to safeguard against the known unknown and the unknown unknown. but alas, i'm bored; to each their own. C Anthony
Re: [arch-general] makepkg creates symlink to the package file
On Wed, Jun 23, 2010 at 7:31 AM, Allan McRae al...@archlinux.org wrote: On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -U pkg at the end of the build and that save you typing the whole PKGDEST path. Allan Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me.
[arch-general] How to install perl plugins in pidgin ?
How to install perl plugins in pidgin ? The default pidgin doesn't have perl support, so I compiled it with --enable-perl from ABS, but the perl plugin in ~/.purple/plugins with executable perm doesn't show up in the list. -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com Cheap and Reliable VPS Hosting: http://j.mp/arHk5e
Re: [arch-general] makepkg creates symlink to the package file
On 06/22/10 19:31, Allan McRae wrote: On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -U pkg at the end of the build and that save you typing the whole PKGDEST path. Allan What about SRCDEST ? Creating a sym link from source package to the build directory would be handy as well.
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On 06/22/10 19:49, Allan McRae wrote: Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive. On 06/22/10 15:21, C Anthony Risinger wrote: i just am having a hard time believing that you are not only going to track down holes, but have the competence to properly fix them, for all the reasons i've already specified. part of the situation is, lots of upstreams don't have security competence either -- especially volunteer-run projects, but I bet some commercial undertakings don't either. So they don't make point-releases as soon as an important security issue is discovered; or they make a patch but the patch is incorrect (often established distros have, in some ways, a better sense of how to patch a security flaw than a individual upstream because the distros see a lot of security flaws -- like buffer overruns, etc). It's clear that spreading more information more quickly about security issues sounds productive, (as long as the information is as correct as can be, which a volunteer team may be able to have some fair amount of competence at, I'm guessing) -Isaac
Re: [arch-general] makepkg creates symlink to the package file
On 23/06/10 11:55, Baho Utot wrote: On 06/22/10 19:31, Allan McRae wrote: On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -U pkg at the end of the build and that save you typing the whole PKGDEST path. Allan What about SRCDEST ? Creating a sym link from source package to the build directory would be handy as well. Do you mean SRCDEST or SRCPKGDEST. The first should already work, the second has a patch on the pacman mailing list. Allan
Re: [arch-general] Arch Linux
On Wed, Jun 23, 2010 at 5:23 AM, John Holbrook johnholbr...@gmail.com wrote: Installed Arch on my X500 and it works amazingly well. Pretty fast and I have a lot of features working that I could never get working with OpenSUSE. T43P works well too, but is there a model X500 from lenovo?
Re: [arch-general] makepkg creates symlink to the package file
On 23/06/10 10:47, Ng Oon-Ee wrote: On Wed, Jun 23, 2010 at 7:31 AM, Allan McRaeal...@archlinux.org wrote: On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -Upkg at the end of the build and that save you typing the whole PKGDEST path. Allan Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me. Possibly... I do not use makepkg -i as I use makepkg -sr so it removed the makedepends that will be unneeded in the future. Using makepkg -c clean up the dangling symlinks. Allan
Re: [arch-general] makepkg creates symlink to the package file
On Tue, Jun 22, 2010 at 10:48 PM, Allan McRae al...@archlinux.org wrote: On 23/06/10 10:47, Ng Oon-Ee wrote: On Wed, Jun 23, 2010 at 7:31 AM, Allan McRaeal...@archlinux.org wrote: On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz - /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS=-j2 CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER=Attilasysad...@hunnen PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to pacman -Upkg at the end of the build and that save you typing the whole PKGDEST path. Allan Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me. Possibly... I do not use makepkg -i as I use makepkg -sr so it removed the makedepends that will be unneeded in the future. Using makepkg -c clean up the dangling symlinks. It is also a very helpful symlink for those of us that like to run namcap after building to check the package. -Dan
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 05:48 Allan McRae wrote: Possibly... I do not use makepkg -i as I use makepkg -sr so it removed the makedepends that will be unneeded in the future. Using makepkg -c clean up the dangling symlinks. I even use makepkg -c too and the symlink is still there. And i never install my own packages with pacman -U because i have my own repo on the server. Therefore i use pacman -S because than i can install it from my other pc too. Or do you mean that a makepkg -c will clean elder invalid symlinks? See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
On 23/06/10 15:11, Attila wrote: Or do you mean that a makepkg -c will clean elder invalid symlinks? This one.
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote: It is also a very helpful symlink for those of us that like to run namcap after building to check the package. That is an advantage ... because i forgot in the most cases to run it and now the motivation to do it is higher.-) See you, Attila
Re: [arch-general] makepkg creates symlink to the package file
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote: It is also a very helpful symlink for those of us that like to run namcap after building to check the package. I must correct myself and have a from my view better idea for this. I suggest a new option -n (or --namcap) which runs namacp after a successful build of a package. If makepkg -cn is used the symlink gets even deleted (or not created) and in the other cases it can stay at this position. Another question: Is there a way to delete this symlink and his target in one step on the command line? Than this symlink could be a bigger help because you get remembered that there is a older package in your repo. At the end i must say that this symlink is not a problem for me and there be advantages too so i can live with it. So please don't see my points as criticism. See you, Attila
