All,
I've been inactive as a developer for a long time now, and I think it's
time for me to go.
It's been an exciting ride with you all. I came on to help launch the
AUR in 2005, and we changed the Arch world forever.
I encourage the new folks to think boldly and put your efforts and
persi
On 08/25/2011 06:08 AM, Ray Rashif wrote:
I share the same sentiments bit for bit, so I am in full agreement
with Dan, JGC, Allan& Ionut. I have always stressed the fact, even
just very recently, to someone who was interested in Arch, that even
though I use Git personally, Subversion makes the m
On 08/18/2011 09:57 PM, Dave Reisner wrote:
Hi Paul,
It looks like dnsmasq is gearing up to release 2.58 in the near future.
I'd like to add in dbus support (means dbus-core as a new dep) and
distribute the upstream systemd service file along with it. Is this okay
with you? If you're short on ti
+1
On 12/29/2010 09:46 PM, Allan McRae wrote:
On 30/12/10 12:16, Dan McGee wrote:
http://www.archlinux.org/packages/community/i686/cower/
Thoughts? I was under the impression we didn't do this, and definitely
on purpose, otherwise people have *no* idea the AUR is different in a
lot of ways. Making
At long last, subversion 1.6.15-1 is ready for signoff. Especially since
it's been a long time since I've updated this package, try some
probably-unique things you do with svn and see if they give you any trouble.
Full changelist is below. No substantive changes to the PKGBUILD.
- P
***
Vers
On 03/22/2010 05:35 PM, Allan McRae wrote:
On 22/03/10 21:11, Jan de Groot wrote:
On Mon, 2010-03-22 at 21:10 +1000, Allan McRae wrote:
On 22/03/10 10:47, Allan McRae wrote:
Changes:
- Fix linking: run "ldd -r /usr/lib/libgdbm_compat.so.3.0.0" on old
package to notice lots of undefined symbols
On 03/16/2010 07:53 AM, Pierre Schmitz wrote:
Am Montag, 15. März 2010 20:16:30 schrieb Thomas Bächler:
No idea if it is time for signoff yet, I have to check that with tpowa.
However, I put 2.6.31.1 in testing with these changes:
- Added a trivial patch to support my touchpad (selfish, I know,
On 03/16/2010 07:54 AM, Dan McGee wrote:
On Tue, Mar 16, 2010 at 6:50 AM, Pierre Schmitz wrote:
Am Dienstag, 16. März 2010 05:50:53 schrieb Dan McGee:
The restart doesn't work at all now
Works fine here. Don't you have the sshd.pid file?
dmc...@dublin ~
$ cat /var/run/sshd.pid
cat: /var/ru
2) A pre-signoff thread for each signoff. You run this thread before
you do
any packaging work, so that if someone wants to discuss other things
about
the package and suggest other modifications, they do it without
causing you
a whole lot of extra work. We then agree not to hijack signoff
threads
Now many months into our regular bug squashing cycle, it occurred to me
today to evaluate our progress.
Summary: We're making excellent progress!
Here's the number of open bugs in Arch Linux (packages) on bug day,
November through March (as determined from the Bug Day TODO page in the
wiki):
There's a confluence of circumstances that occurs regularly now that is
wasting lots of time for those trying to squash bugs:
1) It's really hard to get signoffs for core packages. It usually takes
at least a week, and an extra bump, and coaxing. The process isn't
fire-and-forget, so I have to
On 03/13/2010 04:58 AM, Pierre Schmitz wrote:
Am Samstag, 13. März 2010 01:58:02 schrieb Dan McGee:
I've often wanted to add comments to closed issues in the past and
have been unable to. For things like a performance bug, it is often
helpful a few days down the road to post results of the fix o
On 03/12/2010 06:42 PM, Andrea Scarpino wrote:
On Friday 12 March 2010 23:39:05 Allan McRae wrote:
I really do not see the need.
If a bug is wrongly closed -> request a reopen.
If you just want to confirm a bug has been fixed, there is no need...
we already closed the bug report.
If there is a
On 03/12/2010 05:17 PM, Aaron Griffin wrote:
On Fri, Mar 12, 2010 at 3:28 PM, Thomas Bächler wrote:
Am 07.03.2010 20:41, schrieb Paul Mattal:
Please signoff 1 for each arch.
This is just packaging cleanup, and should have no subtantive impact on
the functioning of vi. Mostly just looking for
On 03/07/2010 02:41 PM, Paul Mattal wrote:
Please signoff 1 for each arch.
This is just packaging cleanup, and should have no subtantive impact on
the functioning of vi. Mostly just looking for an extra sanity check
here, nothing specific to test.
See FS#18215 for details. Highlights
On 03/10/2010 06:13 PM, Allan McRae wrote:
On 11/03/10 09:01, Paul Mattal wrote:
I wanted to ask about how others treat patching.
My understanding of our patching philosophy is:
1) Don't patch if doing so makes us un-vanilla. Users familiar with the
standard behavior of software shou
I wanted to ask about how others treat patching.
My understanding of our patching philosophy is:
1) Don't patch if doing so makes us un-vanilla. Users familiar with
the standard behavior of software should be able to rely on our
packaged versions to behave the same way.
2) If there's some ma
On 03/09/2010 12:19 AM, Allan McRae wrote:
On 09/03/10 14:40, Daniel J Griffiths (Ghost1227) wrote:
On 03/08/10 at 11:32pm, Paul Mattal wrote:
On 03/08/2010 07:16 PM, Allan McRae wrote:
On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:
On 03/08/10 at 05:20pm, Paul Mattal wrote:
On 03
On 03/08/2010 07:16 PM, Allan McRae wrote:
On 09/03/10 08:38, Daniel J Griffiths (Ghost1227) wrote:
On 03/08/10 at 05:20pm, Paul Mattal wrote:
On 03/07/2010 02:33 PM, Paul Mattal wrote:
On 02/25/2010 11:49 AM, Aaron Griffin wrote:
On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths
On 03/07/2010 02:33 PM, Paul Mattal wrote:
On 02/25/2010 11:49 AM, Aaron Griffin wrote:
On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
wrote:
I've always thought the method of modifying your local mirrorlist,
running mkarchroot, then reverting the changes to be more te
I'm trying to build xorg-server from git, in order to bisect some bad
behavior.
It appears the tarball releases and what's in git aren't the same,
though. Right out of the gate, I get:
configure.ac:42: error: must install xorg-macros 1.2 or later before
running autoconf/autogen
configure.ac
This is a bugfix for our site.tmac file. Nothing else is changed.
Previously, if you ran:
$ zcat /usr/share/man/man1/groff.1.gz | groff -man -Tps > foo.ps
this you'd get an initial blank page in your output, and a warning:
grops::6: X command without `ps:' tag ignored
This was due to errant w
Please signoff 1 for each arch.
This is just packaging cleanup, and should have no subtantive impact on
the functioning of vi. Mostly just looking for an extra sanity check
here, nothing specific to test.
See FS#18215 for details. Highlights:
* removed obsolete gcc bug workaround portion of
On 02/25/2010 11:49 AM, Aaron Griffin wrote:
On Tue, Feb 23, 2010 at 7:17 PM, Daniel J Griffiths (Ghost1227)
wrote:
I've always thought the method of modifying your local mirrorlist,
running mkarchroot, then reverting the changes to be more tedious than
necessary for creation of i686 chroots o
On 03/03/2010 07:54 AM, Paul Mattal wrote:
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.html
Any ideas how to fix our
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.html
Any ideas how to fix our ant pkg that I can build OpenJDK again?
On 03/02/2010 10:54 AM, Giovanni Scafora wrote:
2010/3/2, Andreas Radke:
something different: you have bumped apache-ant - please look at this
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-February/008464.html
Any ideas how to fix our ant pkg that I can build OpenJDK again?
I'll leave it in [testing] for 1 week to catch any gotchas.
If no serious issues are identified by then, I will move it to [extra].
- P
On 02/23/2010 10:29 PM, Paul Mattal wrote:
This release addresses a number of packaging issues:
* eliminates the logrotate script (now integrated into syslog-ng)
* warns to restart crond on update to 4.x from earlier major ver
* adds /etc/conf.d/crond for managing commandline options
* adds
On 02/23/2010 10:26 PM, Paul Mattal wrote:
This version adds more log files to syslog-ng's logrotate script, and
should be the only difference.
Log files added since released 3.0.4-1:
/var/log/crond.log
/var/log/lpr.log
/var/log/uucp.log
/var/log/news.log
/var/log/ppp.log
/var/log/debu
This release addresses a number of packaging issues:
* eliminates the logrotate script (now integrated into syslog-ng)
* warns to restart crond on update to 4.x from earlier major ver
* adds /etc/conf.d/crond for managing commandline options
* adds patch to declare LOGNAME env var to be same as U
This version adds more log files to syslog-ng's logrotate script, and
should be the only difference.
Log files added since released 3.0.4-1:
/var/log/crond.log
/var/log/lpr.log
/var/log/uucp.log
/var/log/news.log
/var/log/ppp.log
/var/log/debug.log
Eric also requested I add /var/log/acpid.log,
On 02/21/2010 09:53 PM, Eric Bélanger wrote:
On Sun, Feb 21, 2010 at 9:45 PM, Paul Mattal wrote:
Please signoff, 1 for each arch.
The only difference is that I've added /var/log/crond.log to the logrotate
script so that its rotation is now handled when syslog-ng rotates all its
logs
Please signoff, 1 for each arch.
The only difference is that I've added /var/log/crond.log to the
logrotate script so that its rotation is now handled when syslog-ng
rotates all its logs. The benefit of this is that it's coordinated
properly with the HUPping of syslog-ng, which is the actual c
On 02/09/2010 01:32 PM, Paul Mattal wrote:
This fix just adds a patch to increase the TUBECOLS and TUBESIZE such
that vi will work on larger terminals with default settings/variables
set. Those of use with large console widths have been excited about this
fix:
http://bugs.archlinux.org/task
On 02/09/2010 01:23 PM, Aaron Griffin wrote:
I just want to shoot a welcome message to the newest member of the
team: Dan Griffiths (Ghost1227).
Welcome aboard!
Welcome! I quote below from Damir on my first day.
- P
***
Hi Paul,
Welcome around! Be productive ... but only while having fun!
This fix just adds a patch to increase the TUBECOLS and TUBESIZE
such that vi will work on larger terminals with default
settings/variables set. Those of use with large console widths have
been excited about this fix:
http://bugs.archlinux.org/task/15844
Please signoff both arches. I've tes
On 02/09/2010 08:57 AM, Thomas Bächler wrote:
Am 09.02.2010 14:34, schrieb Dan McGee:
Most importantly, the signoffs are there to verify that neither the
package files nor the contained binaries are corrupted. An i686 signoff
is still necessary to see that the package installs fine and the
binar
On 02/09/2010 03:49 AM, Allan McRae wrote:
On 09/02/10 18:38, Jan de Groot wrote:
These days it looks like almost nobody in our developer team uses i686
anymore. I still have a laptop running it, but I barely use it.
I think both architectures are an issues, although I agree i686 is
worse. The
* Just to show that this actually does happen, this is from my
pacman.log:
The following official packages can be removed since the modules are
now included in the standard perl library:
perl-archive-tar perl-compress-raw-zlib perl-compress-zlib
perl-extutils-cbuilder perl-io-compress-ba
On 02/06/2010 10:29 AM, Allan McRae wrote:
On 06/02/10 09:28, Aaron Griffin wrote:
Message below is trimmed, but the summary is:
pacpan (CPAN wrapper for pacman packages) has been updated with gusto.
There is a request to include using pacpan as part of the official
guidelines for packaging perl
All,
There's been some compelling arguments made in the below bug request to
switch from syslog-ng to rsyslog:
http://bugs.archlinux.org/task/12314
I'm planning to start the process of migrating to rsyslog in March, if a
rough show of hands here confirms it's the right thing to do.
Can peo
On 02/02/2010 12:59 AM, Tobias Powalowski wrote:
Am Sonntag 31 Januar 2010 schrieb Tobias Powalowski:
Hi bump to latest version,
xfsprogs-3.1.1 (29 January 2010)
- Fix various blkid topology support problems in mkfs.xfs.
- Fix various build warnings.
- Add automatic build
I've just put enscript 1.6.5 in testing.
Normally not such a huge event, but enscript has been unmaintained for
years and is now maintained again.
http://git.savannah.gnu.org/cgit/enscript.git/log/
Let me know if you have any feedback. Will push to [extra] in about a week.
- P
On 01/21/2010 09:46 AM, Paul Mattal wrote:
On 01/19/2010 11:35 PM, Dan McGee wrote:
On Mon, Jan 18, 2010 at 9:33 PM, Paul Mattal wrote:
This is the final test release before we go to [core] with the new
crond.
Please signoff, one for each architecture.
Aside from the upstream changes, two
On 01/19/2010 11:35 PM, Dan McGee wrote:
On Mon, Jan 18, 2010 at 9:33 PM, Paul Mattal wrote:
This is the final test release before we go to [core] with the new crond.
Please signoff, one for each architecture.
Aside from the upstream changes, two packaging items:
* I've decided to leav
This is the final test release before we go to [core] with the new
crond. Please signoff, one for each architecture.
Aside from the upstream changes, two packaging items:
* I've decided to leave the crond logrotate script here for now,
unless/until aaron (syslog-ng maintainer) thinks we should
On 01/14/2010 03:37 PM, Tobias Powalowski wrote:
Hi bump to latest version,
xfsprogs-3.1.0 (13 January 2010)
- Reduce memory usage in xfs_repair by using better data structures.
- Add additional checks in xfs_repair to detect freespace btree
corruption instead of only r
On 01/12/2010 04:16 PM, Eric Bélanger wrote:
On Tue, Jan 12, 2010 at 4:04 PM, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 3:01 PM, Eric Bélanger wrote:
On Tue, Jan 12, 2010 at 8:28 AM, Paul Mattal wrote:
In testing 4.2, we've encountered some minor issues, and I have now put
versio
In testing 4.2, we've encountered some minor issues, and I have now put
version 4.3 in testing.
I'd like to get 2 signoffs per arch for this large update.
Here's the changelog since 4.2:
v4.3 11-Jan-2010
* Internal refactoring to make buffer overflow checks
clearer and portability issu
et.
If others feel strongly, I'll remove it from backup, but don't see
much harm in having it there.
- P
On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote:
On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal wrote:
> On 01/06/2010 01:09 AM, Paul Mattal wrote:
> I've
On 01/06/2010 01:09 AM, Paul Mattal wrote:
Proposal: We stay with dcron into the 4.0 series, with a
longer-than-usual testing window so the transition is smooth, and see if
it meets our collective needs. Jim may be willing to add functionality
we find lacking.
Please get your votes and comments
On 01/09/2010 12:49 PM, Tobias Powalowski wrote:
Am Samstag 09 Januar 2010 schrieb Dan McGee:
On Sat, Jan 9, 2010 at 11:23 AM, Tobias Powalowski wrote:
Hi,
since qemu/qemu-kvm 0.12.x kqemu is no longer supported.
kqemu package is removed from the repositories, if you still need kqemu
support
On 01/06/2010 12:59 PM, Thomas Bächler wrote:
Am 06.01.2010 07:09, schrieb Paul Mattal:
* supports anacron-type behaviors
Can you elaborate on that? All I want is that a "missed"
daily/weekly/monthly cron job is executed after boot on a machine that's
not always-on. That
Having now learned more about cron and its many flavors than I probably
ever wanted to know, I am prepared to suggest a course of action. I've
picked up maintenance of dcron from tpowa, and am prepared to move
forward. If we can reach agreement, I'll do the work.
I understand there was a previ
On 01/04/2010 02:43 AM, Tobias Powalowski wrote:
Am Montag 04 Januar 2010 schrieb Paul Mattal:
On 01/03/2010 08:52 PM, Paul Mattal wrote:
Do others have specific experiences with bcron to relate? I know some
folks like Dan and Thomas have chosen fcron, and maybe for good reason
other than just
On 01/04/2010 12:48 AM, Dan McGee wrote:
On Sun, Jan 3, 2010 at 11:45 PM, Allan McRae wrote:
Dan McGee wrote:
Is there anyone willing to bump PostgreSQL to 8.4.2? It is a security
update that we should probably look at sooner rather than later, and
right now almost all of the postgres package
On 01/03/2010 08:52 PM, Paul Mattal wrote:
Do others have specific experiences with bcron to relate? I know some
folks like Dan and Thomas have chosen fcron, and maybe for good reason
other than just features; if you have war stories, please share.
Several other relevant items have come to my
On 01/03/2010 10:28 PM, Allan McRae wrote:
Paul Mattal wrote:
We've got several bugs relating to choosing a new default cron daemon,
and/or supporting other alternatives.
I thought we decided on fcron with the small adjustment/script needed to
support /etc/cron.d in the last rou
We've got several bugs relating to choosing a new default cron daemon,
and/or supporting other alternatives.
The contenders seem to be: dcron, bcron, fcron, vixie-cron.
I have collected facts about these alternatives below, in the hopes we
can make a decision and move forward. Some of these ar
Allan McRae wrote:
Paul Mattal wrote:
Regarding the below:
http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
It reads:
"The -C and -M flags are optional, but it is recommended to provide
these with clean pacman.conf and makepkg.conf files (directly fro
Regarding the below:
http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
It reads:
"The -C and -M flags are optional, but it is recommended to provide
these with clean pacman.conf and makepkg.conf files (directly from the
pacman package) during first creation of clean
Allan McRae wrote:
Paul Mattal wrote:
Giovanni Scafora wrote:
2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg
to build
the package (providing the path to the chroot as an arguement).
Making a chroot for the opposite architecture is slightly more
Giovanni Scafora wrote:
2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg to build
the package (providing the path to the chroot as an arguement).
Making a chroot for the opposite architecture is slightly more difficult,
but I can provide patches if n
Allan McRae wrote:
The tools are very simple to use and are described in the wiki
(http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot).
There is _no_ excuse not to use them. The are minor changes needed for
doing i686 builds on x86_64 and vise versa, but there are pl
James Rayner wrote:
Jan de Groot wrote:
I see a lot of bugs getting closed with "Upstream" lately because
they're not packaging bugs. This is not the way to solve bugs. The only
bugs that should be closed upstream are the ones in binary modules like
flashplugin or nvidia binary drivers. Opensour
Andreas Radke wrote:
Am Mon, 9 Nov 2009 19:27:44 +0100
schrieb Andrea Scarpino :
On 09/11/2009, Jan de Groot wrote:
I see a lot of bugs getting closed with "Upstream" lately because
they're not packaging bugs. This is not the way to solve bugs. The
only bugs that should be closed upstream are
Eric Bélanger wrote:
On Sat, Oct 31, 2009 at 2:38 PM, Paul Mattal wrote:
Dan McGee wrote:
On Sat, Oct 31, 2009 at 6:36 AM, Eric Bélanger
wrote:
Hi,
Is there anyone interested in maintaining slimserver? It's currently
orphaned, out-of-date and doesn't even install (missing
per
Dan McGee wrote:
On Sat, Oct 31, 2009 at 6:36 AM, Eric Bélanger wrote:
Hi,
Is there anyone interested in maintaining slimserver? It's currently
orphaned, out-of-date and doesn't even install (missing
perl-compress-zlib depends FS#16490). If no one wants it, we could
solve all these problems
Aaron Griffin wrote:
On Mon, Oct 26, 2009 at 6:56 AM, Allan McRae wrote:
Hi,
I just committed an update to mailman on SVN trunk. It updates the package
and puts the files in more reasonable places.
However, I have no idea if the changes I made actually work... Can someone
who uses this, bui
Upstream update to xfsprogs 3.0.5.
Please signoff both arches. I have tested basic functionality, just need
another sanity signoff. Because this is a limited-use package, if nobody
signs off within a week (by end of day 11/2) I will push this to core.
Changes are document here in git:
http:/
Roman Kyrylych wrote:
On Thu, Sep 17, 2009 at 02:09, Xavier wrote:
On Wed, Sep 16, 2009 at 10:09 PM, Roman Kyrylych
wrote:
Hi all!
I wanted to bring this long time ago when I discovered the problem
with my old Seagate Momentus 5400.3, but then forgot
since my new WD Scorpio Blue is less affe
Roman Kyrylych wrote:
On Sat, Oct 3, 2009 at 23:56, Paul Mattal wrote:
Please signoff both arches.
Minor change to install scriptlet to avoid error message, closing bug
#16436.
Signed off x86_64.
Anyone for i686?
All you need to do is:
pacman -Rd perl
pacman -S perl (the testing package
Giovanni Scafora wrote:
2009/10/4, Andreas Radke :
what about http://bugs.archlinux.org/task/15311 ?
I only rebuilt it for i686.
The previous signoff was for x86_64 only.
This was actually my fault. I modified the x86_64 package to fix the
no-pdf-documentation bug, and forgot to make it a 2
Please signoff both arches.
Minor change to install scriptlet to avoid error message, closing bug
#16436.
- P
Giovanni Scafora wrote:
2009/10/3, Giovanni Scafora :
please signoff.
I know, the previous signoff was for x86_64 only but now it's too later.
Plese signoff anyway, so I move it to core.
I signoff i686.
- P
Please signoff x86_64 only (it's the only one affected/rebuilt).
This version resolves the missing PDF documentation issue from FS#14517.
Fix was to add:
makedepends=('netpbm' 'psutils' 'ghostscript')
This is the only change.
- P
Allan McRae wrote:
Paul Mattal wrote:
All,
Andrea and I are organizing a bug squashing day this Saturday 10/3,
starting at 1pm EDT and going until we run out of steam (or bugs).
Join us if you can! We'll be around in the main IRC forum.
If you can't make this one, there
All,
Andrea and I are organizing a bug squashing day this Saturday 10/3,
starting at 1pm EDT and going until we run out of steam (or bugs). Join
us if you can! We'll be around in the main IRC forum.
If you can't make this one, there'll always be another. We're hoping to
get onto a monthly sc
Allan McRae wrote:
Paul Mattal wrote:
Allan McRae wrote:
Paul Mattal wrote:
I've been holding back on the libldap and postgresql rebuilds of
postfix, because there's also a list up for db-4.8. Since I have to
rebuild, I'd like to get all 3 at the same time so that testing will
Allan McRae wrote:
Paul Mattal wrote:
I've been holding back on the libldap and postgresql rebuilds of
postfix, because there's also a list up for db-4.8. Since I have to
rebuild, I'd like to get all 3 at the same time so that testing will
be consistent.
However, I haven
I've been holding back on the libldap and postgresql rebuilds of
postfix, because there's also a list up for db-4.8. Since I have to
rebuild, I'd like to get all 3 at the same time so that testing will be
consistent.
However, I haven't seen any db-4.8 packages in testing. What's the
status of
Because of the security vulnerabilities fixed in thunderbird 2.0.0.23, I
decided to build it for myself ahead of schedule. In so doing, I
discovered it wouldn't build for me, and located a patch to fix it.
I attach the modified PKGBUILD and the patch here, perhaps to save some
others some effo
Dan McGee wrote:
On Sun, Jul 12, 2009 at 12:20 PM, Thomas Bächler wrote:
Arch Website Notification schrieb:
Package Name: openvpn
Architecture: x86_64
Repository: Testing
(http://www.archlinux.org/packages/testing/x86_64/openvpn/)
The user provided the following additional text:
Tobias Powalowski wrote:
Am Freitag 15 Mai 2009 schrieb Paul Mattal:
Sorry for the delay. Works fine for me here on i686.
- P
can i move in dmapi xfsprogs? seems not many use this filesystem.
I signoff xfsprogs for i686. As far as I'm concerned, you can move
xfsprogs for x86_64 as
Sorry for the delay. Works fine for me here on i686.
- P
Allan McRae wrote:
Hi all,
With most stuff moved out of [testing], it is a good time to clean up
what is left. Here goes a slightly annotated list:
Just pkgrel bumps - rebuilds for something?
ccrtp
cdrkit
cracklib
libzrtpcpp
proftpd
squid
archboot
aspell-es, aspell-it, aspell-pt - move? B
Requesting signoff for xfsprogs 3.0.0-1, both architectures. It's in
testing for both architectures.
Because xfs is not widely used, if I don't get a second signoff in a
week, I'll move it to core (and xfsdump 3.0.0 to extra).
- P
Dan McGee wrote:
On Wed, Jan 14, 2009 at 1:57 AM, Tobias Powalowski wrote:
Am Donnerstag 25 Dezember 2008 schrieb Tobias Powalowski:
Am Montag 22 Dezember 2008 schrieb Tobias Powalowski:
Hi
update to latest version, please signoff for both arches.
greetings
tpowa
bump
save to move in?
noon
Dan McGee wrote:
On Wed, Jan 14, 2009 at 1:57 AM, Tobias Powalowski wrote:
Am Donnerstag 25 Dezember 2008 schrieb Tobias Powalowski:
Am Montag 22 Dezember 2008 schrieb Tobias Powalowski:
Hi
update to latest version, please signoff for both arches.
greetings
tpowa
bump
save to move in?
noon
I have updated squirrelmail to 1.4.17 for i686.
Can someone build the x86_64 package? It's an easy one, but I won't be
near my x86_64 box until Monday.
- P
Aaron Griffin wrote:
On Mon, Nov 24, 2008 at 7:29 PM, Paul Mattal <[EMAIL PROTECTED]> wrote:
Aaron Griffin wrote:
On Sun, Nov 23, 2008 at 3:39 PM, Eric Bélanger
<[EMAIL PROTECTED]> wrote:
On Mon, 24 Nov 2008, Jud wrote:
Just a quick note to ask if all the Arch Mailing List
Aaron Griffin wrote:
On Sun, Nov 23, 2008 at 3:39 PM, Eric Bélanger
<[EMAIL PROTECTED]> wrote:
On Mon, 24 Nov 2008, Jud wrote:
Just a quick note to ask if all the Arch Mailing List Archives are
working properly? The last archive was Nov 21.
They are not. It's a known issue: http://bugs.arch
On Nov 21, 2008, at 9:01 PM, Aaron Griffin wrote:
Ok, so in an attempt to get around our reliance on the
adjust-permssions script, I added some chmod stuff into the dbscripts,
to automatically g+w all files a given person moves out.
Turns out I didn't know everything. Looks like this only works
Aaron Griffin wrote:
On Thu, Nov 13, 2008 at 1:25 PM, Jason Chu <[EMAIL PROTECTED]> wrote:
On Mon, Nov 10, 2008 at 8:36 AM, Aaron Griffin <[EMAIL PROTECTED]> wrote:
On Sun, Nov 9, 2008 at 8:00 PM, Eric Bélanger
<[EMAIL PROTECTED]> wrote:
On Sat, 8 Nov 2008, Aaron Griffin wrote:
Hey guys,
I w
On Nov 8, 2008, at 7:42 PM, Aaron Griffin wrote:
Hey guys,
I wanted to upgrade ffmpeg to the latest snapshot. Two things came up:
a) Is there a reason we use date stamps for ffmpeg's version? It seems
more straightforward to use the revision number. Any problems with me
switching to that?
See
On Oct 31, 2008, at 8:37 PM, Dan McGee wrote:
On Fri, Oct 31, 2008 at 7:03 PM, Eduardo Romero <[EMAIL PROTECTED]>
wrote:
On Fri, 2008-10-31 at 19:39 -0300, Hugo Doria wrote:
tomcat is using openjdk6 now, so i think jre is ready to be moved.
-- Hugo
Still waiting on eclipse, it needs to be
Eduardo Romero wrote:
On Wed, 2008-10-29 at 09:10 -0400, Paul Mattal wrote:
Looks like no developers are really expressing interest in this. Java
seems like a pretty important package to have in the official repos,
but if no one is willing to maintain it we have ourselves a problem.
Is there a
Dan McGee wrote:
On Sun, Oct 26, 2008 at 11:35 AM, Eduardo Romero <[EMAIL PROTECTED]> wrote:
Well, I have been in discussion with Andreas Radke about the JRE and JDK
packages. Here is the thing, they are both greatly outdated, they are at
u7 when the latest is u10, both have a pending bug and a
1 - 100 of 172 matches
Mail list logo