On Mon, May 02, 2011 at 06:19:36AM +0200, Andrea Scarpino wrote:
> On Sunday 01 May 2011 21:43:42 Jim Pryor wrote:
> > I suggest these changes:
> >
> > --- PKGBUILD2011-05-01 21:30:00.046676526 -0400
> > +++ PKGBUILD.new2011-05-01 21:35:10.0666765
On Mon, May 02, 2011 at 04:06:47AM +0300, Grigorios Bouzakis wrote:
> Jim Pryor wrote:
> > v4.5 was released as a tarball at
> > <http://www.jimpryor.net/linux/dcron.html>; but Paul won't be able to
> > package it right away.
> >
> Pierre already built a
D=33377>, and if you like you
can just add a `git checkout v4.5` to its PKGBUILD and get the same
sources I tarballed.
Please let me know of any difficulties you have; or if you're able to
confirm that scheduling glitches you saw before have gone away. Thanks.
--
Jim Pryor
prof...@jimpryor.net
On Sun, May 01, 2011 at 04:01:01PM +0200, Pierre Schmitz wrote:
> On Sun, 1 May 2011 03:33:37 -0400, Jim Pryor wrote:
> > ...
> > As I said, my source tree contains a large refactoring push. I have
> > deferred this, and back-ported some important bugfixes, and a few s
all be pushed in the next couple of hours.
Thanks, and I apologize for any inconvenience my inability to keep up
with this project has caused anybody.
--
Jim Pryor
profj...@jimpryor.net
elp right at this particular moment, but they
would help the package be more reliably maintained going forward. I'd be
glad to give other interested developers git-push privileges.
--
Jim Pryor
prof...@jimpryor.net
with doing less. And if you
know what's in testing and why, you'll be able to better predict when
doing less will suffice. But I think the only reliably safe general
recipes are the two I stated.
--
Jim Pryor
prof...@jimpryor.net
If you do go #2, you should also rebuild any packages that depend on
libraries installed by Z, and anything that depends on them, and so on.
--
Jim Pryor
prof...@jimpryor.net
want to be sure your "make install"
targets respect DESTDIR. If you leave that out, and run make install as
a normal user, the step will fail and you'll just get an error about not
having privileges (yet) to write to /usr/bin/whatever. If you run make
install as root, though, the files will get written to
/usr/bin/whatever, possibly overwriting what's there, and won't be tar'd
up when $pkgdir is compressed. This is the kind of flimsy but helpful
protection you get from running makepkg as a normal user.
--
Jim Pryor
prof...@jimpryor.net
password at the end for the actual installation. Though
perhaps this is only in the makepkg wrapper I wrote on my own machines.)
--
Jim Pryor
prof...@jimpryor.net
gt; >
> > The new ca-certificates packages does this for you.
>
> Very nice, thank you.
>
> This should also solve Jim's problem, see his reply to my first post.
I'm still using 20090814-3, but I can confirm that doing
# update-ca-certificates --fresh
manually fixes the elinks problem with verifying certificates. Thanks.
--
Jim Pryor
prof...@jimpryor.net
the user.
set connection.ssl.cert_verify = 0
Despite the "extensive configuration" warning, this was working
before, but after rebuilding against openssl 1.0.0, it's not.
The openssl upgrade brought some changes to /etc/ssl/openssl.cnf. I
haven't tracked down yet whether any of those may be responsible for
this.
--
Jim Pryor
prof...@jimpryor.net
On Sat, Feb 06, 2010 at 10:38:02PM +0100, Arvid Picciani wrote:
> Hi,
> i was wondering if anyone maintained a QGtkStyle for use outside
> gnome. Would be duplicated work and i guess i'm not the only one who
> uses gtk styles but not gnome.
There's a qgtkstyle-svn in AUR.
rating pacman
wrapper will make that happen automatically, but you might well decide
it's still more trouble than you're looking for.
(I submitted a bunch of changes to customizepkg-new a few months ago but
I don't think they've been folded in yet.)
--
Jim Pryor
prof...@jimpryor.net
it
> yet (which of course makes perfect sense).
There is a wiki page for the development version too, I think it's
linked from that forum thread.
--
Jim Pryor
prof...@jimpryor.net
t's not obvious
cdrtools is in the clear, the case against cdrkit seems stronger, so if
one is to be distributed it should be cdrtools
trust other distros, and decide we're clear to distribute either, in
which case the technical merits again speak for cdrtools.
--
Jim Pryor
j...@jimpryor.net
lable then.
Also, Arch is in the process of moving to a different initcpio system.
It's not in any of the repos yet, but is in the pipeline. I haven't
fully understood what the changes will be. I think they're getting rid
of the use of klibc.
I expect others who do know better will chime in.
--
Jim Pryor
prof...@jimpryor.net
ove conforms to the RFC's and reusing the 127.0.0.1
> address can confuse some apps.
>
> I have been using the above and it has always worked, no busted apps.
This also seems to work for me, at least the extra aliases at the end of
the line are respected:
#
127.0.0.1 localhost.localdomain localhostarch
--
Jim Pryor
prof...@jimpryor.net
On Tue, Jan 12, 2010 at 08:41:47PM -0600, Dan McGee wrote:
> > Very nice. When did you guys do that?
>
> Forever? It is in the initial git import from 2005, which is the
> beginnings of pacman 3.X:
> http://projects.archlinux.org/pacman.git/tree/src/pacman/package.c?id=d04ba#n85
Just shows: read
On Tue, Jan 12, 2010 at 05:50:47PM -0600, Aaron Griffin wrote:
> On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler wrote:
> > pacman -Qii is your friend.
>
> This.
> pacman -Qii dcron will show you all the backup files that pacman will
> take care of.
Very nice. When did you guys do that?
On Tue
On Wed, Jan 13, 2010 at 01:34:52AM +0200, Dimitrios Apostolou wrote:
>
> Since I've been bitten by this, how can I know if the file I
> modified is goint to be overwritten or not, *before* it actually
> happens?
pacman -Qo $file
will tell you what package installed $file.
find /var/abs
On Tue, Jan 12, 2010 at 04:28:40PM -0500, Paul Mattal wrote:
> On 01/12/2010 04:16 PM, Eric Bélanger wrote:
> >>>As the dcron logging is now managed by syslog-ng, it shouldn't provide
> >>>a /etc/logrotate.d/crond. Instead, we should release a new syslog-ng
> >>>package with /var/log/crond.log add
n backup array, and should instead always be explicitly protected by
the
user if user wants to mod?
No problem if so, it's actually helpful to know there's an explicit policy to
always do it the one way or always do it the other way.
As to dcron 4.2, I've already gotten
use mkinitcpio 0.5.27-1 in [testing].
Or boot using the fallback kernel image, which doesn't use autodetect.
And wait until mkinitcpio makes it way to the core repos.
--
Jim Pryor
prof...@jimpryor.net
On Tue, Jan 05, 2010 at 06:03:32PM -0500, Jim Pryor wrote:
> Hi this is the author of yacron again.
>
> I've just heard from Matt Dillon, he says he's happy for me to take over
> development and maintainership of dcron.
>
> So what I'll do is create a release ve
27;s happy for me to take over
development and maintainership of dcron.
So what I'll do is create a release version of yacron, and rename it to
dcron 4.0. Of course that doesn't mean Arch has to keep using dcron; you
may still decide fcron is better for core. But if you do want to stay
with dcron, its development will now continue with the features I had
forked as yacron.
--
Jim Pryor
prof...@jimpryor.net
I've several times wanted to reply to
arch-dev-public emails and didn't know how. It's helpful to hear this is
the expected protocol, thanks.
--
Jim Pryor
prof...@jimpryor.net
I could add the extra features I needed but still keep to
the tiny codebase. At this point, the upside of yacron is that
simplicity (for however much you value it). The downside is---I'll be
honest---not many people have been using it. But then I've
had no problem reports, the code is really tiny and I tested/scrutinized
my changes carefully, and the dcron starting point is quite mature.
--
Jim Pryor
prof...@jimpryor.net
28 matches
Mail list logo
