Re: [arch-general] makepkg creates symlink to the package file
On Thu, Jun 24, 2010 at 1:07 PM, Attila vodoo0...@sonnenkinder.org wrote: For me this link is now a good help (and memory) to run namcap which i forgot in the most cases and therefore i found my peace with it. But i can understand the wish for a config variable if some don't need this. ...but that's the whole point of bash/zsh completion. Do you put links to $HOME in /etc or use CDPATH? I mean, modern shells have facilities so let's use them. Joining the list of people that think these links are unnecesary. Andres P
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
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] Important notice on the Arch Security Team to the whole Arch Linux community.
2010/6/21 Ng Oon-Ee ngoo...@gmail.com: bugs with upstream, which may not be the case with 5-10 security-patches from git/svn). This is just pessimistic outlook. Having patches means that you're actually contributing upstream instead of leaching the latest ver every 3 weeks. People need to stop with the notion that patching is bad. As long as you submit upstream, it's anything but a detriment. Upstream *wants* you to fix their crap. Andres P
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
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
Re: [arch-general] New Google Group for discussion and notices on Arch security.
On Fri, Jun 18, 2010 at 1:18 AM, Jeffrey 'jf' Lim jfs.wo...@gmail.com wrote: ah yes, SSL! sorry :) On 2006-05-01 22:34:12, Ulf Möller, openssl developer [1], responded [2] to openssl packager Kurt Roeckx [3] saying that he was for applying the patch just to keep valgrind quiet. But openssl doesn't like to talk about that, and neither does slashdot for that matter. For a distro packager, the maximum authority regarding what to do with a given piece of software is upstream and common sense. If upstream says it's a ok, then common sense takes a backseat during technical discussions. Not to mention that initializing variables like that is undefined and bound to *always* cause confusion. Andres P [1] http://openssl.org/about [2] http://marc.info/?l=openssl-devm=114652287210110w=2 [3] http://qa.debian.org/developer.php?login=k...@roeckx.be
Re: [arch-general] New Google Group for discussion and notices on Arch security.
On Thu, Jun 17, 2010 at 10:18 PM, Jeffrey 'jf' Lim jfs.wo...@gmail.com wrote: On Fri, Jun 18, 2010 at 8:33 AM, C Anthony Risinger anth...@extof.me wrote: security is the responsibility of those deploying, not those packaging. it requires end-to-end oversight and complete configuration toward a specific and particular purpose; something that is not possible for those creating a distribution for a generic, multi-purpose user base. 2 words. Debian, and SSH. Did you mean ssl? Andres P
Re: [arch-general] [arch-dev-public] [signoff] pacman 3.4.0-1
On Wed, Jun 16, 2010 at 10:04 PM, Dan McGee dpmc...@gmail.com wrote: Upstream release, please signoff. Small detail, Optional Deps : fakeroot: for makepkg usage as normal user python: for rankmirrors script usage rankmirrors is now bash. Andres P
Re: [arch-general] File Associations for firefox thunderbird :)^
On Mon, Jun 14, 2010 at 10:39 AM, Nilesh Govindarajan li...@itech7.com wrote: I am a full time KDE user and I don't have GNOME or its libraries. Firefox and Thunderbird keep asking me to choose applications to open .pdf, .doc, .xls, http://, etc. Is there no package which can fix the file associations for FF and TB ? Does mozilla work with ~/.mailcap? :/ Andres P
Re: [arch-general] [arch-dev-public] [PATCH] Do not refer to $startdir/{src, pkg} in PKGBUILDs
2010/6/8 Allan McRae al...@archlinux.org: It is very rare that you should ever need to use $startdir in a PKGBUILD at all. I exclude config.h from dwm's PKGBUILD $source array and copy it from $startdir during build(). It's changed constantly so keeping it summed check is awkward, and I don't want to loose the sumcheck for the rest of sources. Maybe $sources should have a per entry ! or @ prefix that disables sum checks for that file. This could be extended to make one of the !@ chars skip extraction, since duplicating the filenames in $noextract is less practical. Andres P
Re: [arch-general] [arch-dev-public] [PATCH] Do not refer to $startdir/{src, pkg} in PKGBUILDs
On Tue, Jun 8, 2010 at 8:03 PM, d...@falconindy.com wrote: On Tue, Jun 08, 2010 at 07:58:55PM -0430, Andres P wrote: 2010/6/8 Allan McRae al...@archlinux.org: It is very rare that you should ever need to use $startdir in a PKGBUILD at all. I exclude config.h from dwm's PKGBUILD $source array and copy it from $startdir during build(). It's changed constantly so keeping it summed check is awkward, and I don't want to loose the sumcheck for the rest of sources. Maybe $sources should have a per entry ! or @ prefix that disables sum checks for that file. This could be extended to make one of the !@ chars skip extraction, since duplicating the filenames in $noextract is less practical. Andres P Rebuilding as 'makepkg -efi' means that checksums are skipped since you're asking makepkg to use what's already extracted in $srcdir d That does not account for PKGBUILD updates, namely $pkgver changes. bsdtar will overwrite config.h with the new extracted tar's contents If makepkg were as fluid as /usr/share/mk in *BSD, this wouldn't be such an issue. ;) Andres P
Re: [arch-general] [arch-dev-public] [RFC] Rewrite early RTC device creation
On Tue, Jun 8, 2010 at 9:23 PM, Dan McGee dpmc...@gmail.com wrote:
We can also just do some bash string manipulation and leave sed out of
the picture:
devnum=$(cat /sys/class/rtc/rtc0/dev)
/bin/mknod /dev/rtc0 c ${devnum/:/ }
Since you're already using a ${foo/bar/baz} bashism, that's a useless
use of cat:
devnum=$( /sys/class/rtc/rtc0/dev)
And the subshell is also unnecesary:
read -r devnum /sys/class/rtc/rtc0/dev
The second one is posix...
Andres P
Re: [arch-general] [arch-dev-public] [PATCH] Do not refer to $startdir/{src, pkg} in PKGBUILDs
On Tue, Jun 8, 2010 at 11:02 PM, Allan McRae al...@archlinux.org wrote:
On 09/06/10 10:38, Andres P wrote:
If makepkg were as fluid as /usr/share/mk in *BSD, this wouldn't be
such an issue. ;)
I have no idea what /usr/share/mk does in this regards so you will need to
explain more.
In *bsd, make sources from /usr/share/mk for packages in core/base,
and in /usr/share/pkgsrc/mk (in netbsd; freebsd and obsd use
..ports/{Mk,infastructure}). This effectively couples make timestamp
based builds with a nice library to handle all types of states.
They have different identifiers and directories for distfiles,
patches, and src files that directly reside in the ports db. The
latter being the equivalent for source=() files in arch that get
copied from $startdir. Their Makefiles are fully reentrant if you
peruse these vars instead of using a giant source=() inclusion.
The sum check is specified in another file, like Crux's .md5sums.
Taking this in mind, I can declare config.h outside the distfiles
directory and still have it copied to ./src, have the other files
still be sum checked, and independantly build from extracted sources
or decide to untar from scratch...
Andres P
Re: [arch-general] test
On Fri, May 28, 2010 at 09:21:07AM +0530, Nilesh Govindarajan wrote: On Fri, May 28, 2010 at 7:58 AM, papul mkakati2...@gmail.com wrote: Sorry for this useless message. testing some service. You're send a test message to 500-1000 people on a mailing list. Idiotic. Create a mail account on another provider and test your thing. Don't annoy us. Mr. Aaron may ban you if you do this once more. -- Nilesh Govindarajan Facebook: nilesh.gr Twitter: nileshgr Website: www.itech7.com Jesus... calm down man. Mr Aaron... really? -- Andres P
