Xavier schrieb:
it is written in the pkgbuild :
# pacman.static build fails unless we keep the libtool files (or unless we link
# the missing symbols inside the libarchive .a static lib, but that is dirty)
options=(libtool)
though pacman.static is no longer in pacman package, but afaik there
is
Tobias Powalowski schrieb:
Hi
bump to latest udev version.
greetings
tpowa
/arch/signoff64
signature.asc
Description: OpenPGP digital signature
Allan McRae schrieb:
Hi all,
I have just push devtools-0.7.0-1 to our repos. It comes with support
for arch-any packages, split packages and the community repo.
Some things that people should note:
- you need a commit message when using (e.g.) extrapkg or the commit
will fail.
-
Eric Bélanger schrieb:
Yep, it should work fine.
It seem to have worked fine. BTW, why don't we create testing2coreany
and testing2extraany scripts? It would be be more convenient than
using db-move directely.
Hm, why not simply with testing2x? If the package is not in core/extra
yet,
Eric Bélanger schrieb:
testing2x will not work. you need to explicitely tell db-move that
it's an any arch package, e.g:
/arch/db-move festival-rablpc16k testing extra any
testing2x only runs:
$(dirname $0)/db-move ${pkg} testing ${repo} ${_arch}
where _arch is either i686 or x86_64. Until
Ronald van Haren schrieb:
Hey guys,
this morning I synced my old i686 laptop to testing, thereby upgrading
the kernel to 2.6.31 and such. I did so when I was in the train (I
downloaded the packages already at home) on the way to my internship. I
rebooted the system after the upgrade, but it
Roman Kyrylych schrieb:
+1 for spreading more the noise about this.
This was the opinion I expressed in this old thread :
http://bbs.archlinux.org/viewtopic.php?id=39258
Anyone else has some opinion about how to handle this?
Wow, I had this problem when switching to ext4 and thought my
Allan McRae schrieb:
Upstream update. Add attr dep.
Signoff both.
Allan
/arch/signoff64
signature.asc
Description: OpenPGP digital signature
Fixes http://bugs.archlinux.org/task/16095
Please sign off.
signature.asc
Description: OpenPGP digital signature
Thomas Bächler schrieb:
Fixes http://bugs.archlinux.org/task/16095
Please sign off.
Was still broken, now it should be fixed, please sign off.
signature.asc
Description: OpenPGP digital signature
So, please have a look at the second block:
if [ $1 != ]; then
svn commit -m upgpkg: $pkgbase $pkgver-$pkgrel
$1 /dev/null
if [ $? -ne 0 ]; then
echo Cancelled
exit 1
fi
echo === Commited with \upgpkg: $pkgbase $pkgver-$pkgrel
$1\ message
else
svn
Xavier schrieb:
2) The above is easy to fix, however, the Commited with ... message is
incorrect. Furthermore, we should still include upgpkg: ... in the default
commit message, that is missing in the second code path.
first commit after 0.7.0 :)
Aaron Griffin schrieb:
This would work, assuming all the error handling is in place (i.e.
ensure editor can be called, if undefined, use vi by default, ensure
return value before committing, ensure non-zero length commit
message).
What about the simple way:
if [ -z $1 ]; then
echo Please
Aaron Griffin schrieb:
What about the simple way:
if [ -z $1 ]; then
echo Please ...
exit 1
done
This way, the editor code path could be removed again.
If someone wants a more complex commit message, take Francois' aproach and
svn commit manually before calling XXXpkg.
A simple commit
Aaron Griffin schrieb:
We've had a few bugs regarding the issue of our crappy default cron.
http://bugs.archlinux.org/task/16085
http://bugs.archlinux.org/task/12910
The consensus among the people who have commented is that fcron is the
best bet here.
So let's do this. Would someone like to
Aaron Griffin schrieb:
Another suggestion was vixie-cron - personally I have been using fcron on
LFS since 2001 or 2002 and later on Arch, and have been happy with it all
those 8 or 9 years. Whatever we do by default, I will keep on using fcron.
It sounds like you're a little hesitant about
Kernel is in testing for both architectures, please sign off (at least
one for x86_64, two for i686).
I think tpowa had the kernel all ready to move to core, except he was
waiting for the .1 release, which is there now.
The only thing bugging me is http://bugs.archlinux.org/task/16149,
This is a small daemon that was originally part of autowifi. It will be
a depend or optdepend on the next netcfg's auto-wireless mode. This will
be a reliable wireless roaming mode.
The daemon is somewhat similar to wpa_cli -a $script, but adds logging
and avoids race conditions by adding a
Pierre Schmitz schrieb:
Am Sonntag 27 September 2009 16:01:38 schrieb Thomas Bächler:
Package is in testing for review.
How should we test this? Will there be a new netcfg soon? Why not include iths
in netcfg or might tis be usefull stand-alone?
1) netcfg can be -any
2) I maintain
Allan McRae schrieb:
Upstream update, added info install script.
Signoff both,
Allan
Signoff 64.
signature.asc
Description: OpenPGP digital signature
Damjan Georgievski schrieb:
Just be aware of this problem
http://bbs.archlinux.org/viewtopic.php?pid=627145
This Arch user lost /dev/tty0,1,2,3 device nodes on boot with 2.6.31
from the Arch testing repositry.
A friend of mine also had the same issue with a self compiled 2.6.31.
On my laptop
Andreas Radke schrieb:
the db-remove script removes also all stuff from svn incuding trunk
expect the topdir, right? that's not what I want. any simple way to only
svn rm repos/* + get the pkg away from the ftp?
Last time I tried, it didn't touch trunk at all.
signature.asc
Description:
Eric Bélanger schrieb:
Bump. Anyone?
Two weeks in testing, no bug reported. I've moved it to core.
I'm wondering, does anyone actively use GPM? I haven't in a long time,
although I always found it awesome to have a mouse on the terminal.
signature.asc
Description: OpenPGP digital
Eric Bélanger schrieb:
device-mapper lvm2 2.02.53-1 are now in testing.
Changes: Minor upstream update.
Please test and signoff.
I don't reboot that often, but vgdisplay and lvdisplay are still fine,
signoff64.
signature.asc
Description: OpenPGP digital signature
Ronald van Haren schrieb:
In testing for both architectures, please signoff.
Changes:
- new upstream release
Ronald
/arch/signoff64
signature.asc
Description: OpenPGP digital signature
See:
http://mailman.archlinux.org/pipermail/arch-commits/2009-October/062928.html
Giovanni, I hate to have to point fingers here, but before making such a
change to somebody else's package, it should be discussed here. Now we
have split the big package into many small ones - that's okay. But
Thomas Bächler schrieb:
See:
http://mailman.archlinux.org/pipermail/arch-commits/2009-October/062928.html
Giovanni, I hate to have to point fingers here, but before making such a
change to somebody else's package, it should be discussed here. Now we
have split the big package into many
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
See:
http://mailman.archlinux.org/pipermail/arch-commits/2009-October/062928.html
Giovanni, I hate to have to point fingers here, but before making such a
change to somebody else's package, it should
Giovanni Scafora schrieb:
2009/10/1, Thomas Bächler tho...@archlinux.org:
See:
http://mailman.archlinux.org/pipermail/arch-commits/2009-October/062928.html
Can you read Giovanni or Andrea?
You should SEE before to write, not after:
Author: andrea
Yeah, sorry, I was looking at
http
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
It was partially broken before: ALL .xpi files have to be in
noextract=(...) for it to make sense. And they must be extracted all
separately, otherwise they will all have the same (wrong) .manifest file.
Ok
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
We can't do much more I guess. At least the conflict should be there.
added conflicts to -3 and uploading they...I am opening a topic on forum.
The packages are still broken, because they all use a wrong
Thomas Bächler schrieb:
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
We can't do much more I guess. At least the conflict should be there.
added conflicts to -3 and uploading they...I am opening a topic on forum.
The packages are still broken, because
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
The packages are still broken, because they all use a wrong manifest
file. But I already wrote that in a previous mail, please look at your
original patch and see which code you deleted, then wonder why this code
Andrea Scarpino schrieb:
On 02/10/2009, Thomas Bächler tho...@archlinux.org wrote:
See my last post, I seem to be reading only half of what is on my screen
today.
Luckily I am not the only one distracted today :)
Packages look good, users warned. Goodnight!
Good night to you too
Allan McRae schrieb:
The pkgdesc's are still stupid
pacman -Ss thunderbird
extra/thunderbird 2.0.0.23-1
Standalone Mail/News reader
extra/thunderbird-af 2.0.0.23-3
Language packs for Thunderbird
extra/thunderbird-be 2.0.0.23-3
Language packs for Thunderbird
extra/thunderbird-bg
I keep getting many init feature requests for more fancy and cool
features in crypttab. Now, the crypttab file format is unflexible and
extending it makes the code pretty much unreadable an unmaintainable.
This is what I am planning:
- Rewrite crypto support in initscripts, with a new
Another upstream release, I want to move directly after signoff.
Last minute changes:
- Changed number of maximum serial ports to 32
- Enabled ATI KMS (if this causes problems, blame Andy, he says it's
fine :D)
Working fine on x86_64, i686 will be ready soon.
signature.asc
Description:
Andreas Radke schrieb:
Fixing this one:
[andy...@workstation64 trunk]$ LANG=C man modprobe.d
man: can't open /usr/share/man/modprobe.conf.5: No such file or
directory
and that was one reason why man-db always recreates the database, see
http://bugs.archlinux.org/task/14467 .
please signoff
Thomas Bächler schrieb:
Another upstream release, I want to move directly after signoff.
Last minute changes:
- Changed number of maximum serial ports to 32
- Enabled ATI KMS (if this causes problems, blame Andy, he says it's
fine :D)
Working fine on x86_64, i686 will be ready soon
Andreas Radke schrieb:
Am Thu, 08 Oct 2009 13:21:07 +0200
schrieb Thomas Bächler tho...@archlinux.org:
Thomas Bächler schrieb:
Another upstream release, I want to move directly after signoff.
Last minute changes:
- Changed number of maximum serial ports to 32
- Enabled ATI KMS
Daniel Isenmann schrieb:
Hi,
at the moment the mono packages are spread across our repos
(extra, community and some AUR packages). I would like to complete and
concentrate our support and adding some new packages to [extra]. As you
can see (here: http://ftp.novell.com/pub/mono/sources-stable/ )
Thomas Bächler schrieb:
Thomas Bächler schrieb:
Another upstream release, I want to move directly after signoff.
Last minute changes:
- Changed number of maximum serial ports to 32
- Enabled ATI KMS (if this causes problems, blame Andy, he says it's
fine :D)
Working fine on x86_64, i686
I want to update and reboot gerolde in about 9 hours. Please save all
important work around that time, I will announce this again on the IRC
channel a few minutes before I start.
Expected downtime is less than 5 minutes, developer ssh access, rsync,
devftp and git/svn checkout via gudrun will
Thomas Bächler schrieb:
I want to update and reboot gerolde in about 9 hours. Please save all
important work around that time, I will announce this again on the IRC
channel a few minutes before I start.
Expected downtime is less than 5 minutes, developer ssh access, rsync,
devftp and git/svn
Thomas Bächler schrieb:
I want to update and reboot gerolde in about 9 hours. Please save all
important work around that time, I will announce this again on the IRC
channel a few minutes before I start.
Expected downtime is less than 5 minutes, developer ssh access, rsync,
devftp and git/svn
New upstream release, please sign off.
signature.asc
Description: OpenPGP digital signature
Allan McRae schrieb:
New upstream release, please sign off.
sign off x86_64
x86_64++
signoff i686
Allan
Nobody uses i686, right? Anyone else for i686?
signature.asc
Description: OpenPGP digital signature
Just a few random upstream fixes, please sign off.
x86_64 is tested and available in testing
i686 is still building, it will be there in about an hour, I won't write
a separate message about it.
signature.asc
Description: OpenPGP digital signature
Aaron Griffin schrieb:
If you propose a tool that will turn SVN commits into an RSS feed, I
will gladly set it up. As far as I know, they're not going to be as
easy to use as you'd like here (with the picking and choosing part).
Example: http://eds.activemath.org/en/node/209
Here's an idea.
Roman Kyrylych schrieb:
On Wed, Oct 14, 2009 at 00:07, Aaron Griffin aaronmgrif...@gmail.com wrote:
Here's an idea. Considering we no longer have CVS repos displayed on
repos.archlinux.org, we could switch to an SVN only web viewer that
supports this.
Allan McRae schrieb:
Allan McRae wrote:
Dan McGee wrote:
On Wed, Oct 7, 2009 at 7:57 AM, Allan McRae al...@archlinux.org wrote:
Upstream update.
Signoff x86_64
Anyone extracted a file on i686?
The only time I extract files on i686 is when using makepkg, but that
doesn't use
Allan McRae schrieb:
The only time I extract files on i686 is when using makepkg, but that
doesn't use gzip, but zlib - most people will never use gzip directly
like that.
I think you can just move it, provided nobody seems to care.
If it helps, gzip is used to compress man and info pages
Allan McRae schrieb:
So if splitting these is OK:
1) where do fortran and objc libs go? gcc-libs or their own package.
The later requires dependency fixing...
2) can I bring in a gcc-ada package at the same time? I have a local
gcc package that I can use to bootstrap it.
Allan
In
Daniel Isenmann schrieb:
Alright, then I will do it manually. Have I the rights to delete a
package in community? Never tested before.
You'll need an account on sigurd and must have the right groups, obviously.
signature.asc
Description: OpenPGP digital signature
Upstream update, please sign off (due to the low usage of this package
among developers, I also ask users to sign off).
signature.asc
Description: OpenPGP digital signature
Upstream update, please sign off (due to the low usage of this package
among developers, I also ask users to sign off).
signature.asc
Description: OpenPGP digital signature
Andreas Radke schrieb:
I've built the new Xorg 7.5 based on xorg-server 1.7.1rc1 and Mesa 7.6.
Some very old drivers have been dropped because they are no more
developed and won't build anymore.
I hope I have updated all essential parts. Some Xorg fonts related
packages still need a bump.
Andreas Radke schrieb:
I'd like to see tests with new kernel 2.6.32 drm module before we make a
decision to whether stay with gallium or revert to dri drivers.
It shouldn't be too far away.
-Andy
Kernel is expected in 6 weeks or so, X shouldn't have to stay in testing
that long. Currently,
So, I wanted to revisit the subject of udev rules. Right now, we have
rules in /etc/udev/rules.d and /lib/udev/rules.d - the idea was that
upstream rules goes to /lib and whatever else goes to /etc.
This was interpreted by some of our own dev team that we should put
whatever udev and packages
Giovanni Scafora schrieb:
2009/10/20, Thomas Bächler tho...@archlinux.org:
- All our packages should have udev rules in /lib only.
You're right here.
Well, do I should fix my kino package, adding
--with-udev-rules-dir=/lib/udev/rules.d ?
Let me know.
I hope so. The consensus last time we
Aaron Griffin schrieb:
I don't remember the previous discussion too well, but judging from
the current state of things (rules we ship being all over the place),
I would say you are right as well
I'm glad you don't :)
We should gradually move rules over to /lib.
I was looking into this
Giovanni Scafora schrieb:
core/device-mapper
Eric, I can fix device-mapper, as there is something to change here (I
think they even have upstream rules now), see
http://bugs.archlinux.org/task/16735
core/pcmciautils
core/udev
udev just includes the empty directory, pcmciautils should be
I put new klibc, klibc-kbd, klibc-m-i-t, klibc-udev, klibc-extras and
v86d to testing. Those are no version bumps, but just a rebuild of klibc
against 2.6.31 with a small bugfix (see more below) - and the
corresponding rebuilds for the new ABI, as with each change of build
headers for klibc.
Firmicus schrieb:
Yes, that's what happened, I should have made it clearer. Thanks Eric
for fixing it.
Aaron, could I be granted the right to move pkgs to core in the future?
Essentially this would only concern perl.
I guess it is safe to assume you won't break our core package set, I
added
Thomas Bächler schrieb:
I put new klibc, klibc-kbd, klibc-m-i-t, klibc-udev, klibc-extras and
v86d to testing. Those are no version bumps, but just a rebuild of klibc
against 2.6.31 with a small bugfix (see more below) - and the
corresponding rebuilds for the new ABI, as with each change
Thomas Bächler schrieb:
Signoff procedure:
1) cp /boot/kernel26.img /boot/kernel26.img.working
2) pacman -Syu
3) mkinitcpio -p kernel26
4) reboot
i686 packages are completely untested, x86_64 works and boots.
Okay, Eric says it doesn't work on i686 - I don't know why, but please
don't forget
Allan McRae schrieb:
I can confirm:
::Loading udev... clocksource tsc unstable (delta = 1720416923ms)
Newer udev doesn't work with klibc, it requires blkid, which we will
probably never be able to build with klibc.
I want to get rid of klibc - it sucks, it's a nightmare, it's
Allan McRae schrieb:
Just adding that I tried heaps of clocksource= options
(acpi_pm,htc,jiffies,rtc) and none of them helped this issue.
Allan
That clocksource message is probably unrelated - I get similar messages
after successful boot. Eric didn't get those, but got a message about
his
I put new packages to /home/thomas/klibc-testing-i686/new, can anyone
try if those change anything?
signature.asc
Description: OpenPGP digital signature
Aaron Griffin schrieb:
On Thu, Oct 22, 2009 at 3:35 AM, Thomas Bächler tho...@archlinux.org wrote:
I put new packages to /home/thomas/klibc-testing-i686/new, can anyone try if
those change anything?
I suspect this stems from the signal stuff that you patched in klibc.
As a trial, can you try
New upstream release, please sign off.
Everyone who installed the broken testing/klibc updates for i686, do
yourself a favor and revert to the versions in core again BEFORE
installing a kernel update (pacman -S klibc klibc-extras klibc-kbd
klibc-module-init-tools klibc-udev (v86d)), as you
What do you think of removing those?
[10:14:28][tho...@gerolde ftp]$ ls -lhF current core/os/*/current*
lrwxrwxrwx 1 ftp ftp-arch 14 2008-11-21 02:41
core/os/i686/current.db.tar.gz - core.db.tar.gz
lrwxrwxrwx 1 ftp ftp-arch 14 2008-11-21 02:41
core/os/x86_64/current.db.tar.gz - core.db.tar.gz
Allan McRae schrieb:
Hi,
Does anyone care to maintain openswan in [core]. It is quite out of
date and currently and orphan.
Allan
Tom maintained it back in the days. I wonder if we really need it in
core - does anyone need ipsec for their internet access?
signature.asc
Description:
Allan McRae schrieb:
Allan McRae wrote:
Hi all,
Now I have move the fortran and objc libs back to the gcc-libs
package, it is time to signoff the toolchain for the binutils-2.20
rebuild. This encompasses the following packages:
kernel-headers-2.6.31.4-1
binutils-2.20-1
glibc-2.10.1-5
Allan McRae schrieb:
Hi,
I have just noticed that it appears currently not possible to have split
packages that have some packages in [core] and others in [extra]. This
make the gcc split a lot less attractive (gcc-{fortran,objc,ada} are all
currently in [core] and not [extra] where I
Aaron Griffin schrieb:
What would need to be done to make this easier? If the above works
(and I don't know why it wouldn't), it seems fairly straightforward to
me.
- testingpkg, extrapkg etc. and so on need to be able to push packages
to different staging directories and commit to multiple
Changes: Create /var/empty in the init script if it doesn't exist
already - sshd will refuse to start otherwise.
Please sign off both architectures.
signature.asc
Description: OpenPGP digital signature
Okay, it is obvious that we need a kernel which can run on Xen domU for
our servers. It would also be very convenient for those running Arch on
hosting services that have pv-grub available.
Until now, I compiled a modified version of the kernel26 package with
pv_ops/Xern enabled which - in
Jan de Groot schrieb:
On Fri, 2009-10-30 at 02:12 +0100, Pierre Schmitz wrote:
What about an 4th option: Add xen support to the lts kernel which is
meant for
servers anyway.
Which is probably broken because pvops/xen matured after 2.6.27?
That, and I doubt the lts kernel will be around
Pierre Schmitz schrieb:
Fair enough. So as long as this change does not introduce püroblems or
decrease of performance for the average desktop user I am fine with whatever
you like.
The performance question is hard to answer - however, as we have pv_ops
enabled anyway, I guess there will be
RedShift schrieb:
Thomas Bächler wrote:
Okay, it is obvious that we need a kernel which can run on Xen domU
for our servers. It would also be very convenient for those running
Arch on hosting services that have pv-grub available.
What about dumping Xen in favor of KVM and move libvirt
Pierre Schmitz schrieb:
Am Samstag 31 Oktober 2009 09:07:59 schrieb Dieter Plaetinck:
anyone with superpowers can fix? don't forget to commit the result ;)
updated and commited; though I cannot push the changes because the filesystem
is read-only. (Bug or feature?)
Erm, what exactly is
Thomas Bächler schrieb:
updated and commited; though I cannot push the changes because the
filesystem is read-only. (Bug or feature?)
Erm, what exactly is read-only?
Yeah, gudrun is not supposed to push data anywhere. Instead, you need to
edit/commit locally, push to gerolde as usual so
Roman Kyrylych schrieb:
I would love to get there too.
Not sure if my company will sponsor me again this time,
but if I could keep traveling cost to the minimum
I'll be able to get there with my own money only.
I will need to get a new visa though. :-/
Anyone else would like to join the party?
Tobias Powalowski schrieb:
Hi guys,
Since xorg has moved to extra repository,
we will have broken nvidia legacy drivers:
http://www.nvnews.net/vbulletin/showthread.php?t=139388highlight=x.org
Pierre tested this, and this also concerns the 173 series.
signature.asc
Description: OpenPGP
Andreas Radke schrieb:
Please sign off both architectures.
I also got locked out. Signoff both.
And also moved it to core.
Thanks Andy.
signature.asc
Description: OpenPGP digital signature
Tobias Powalowski schrieb:
Dieter
What about adding the legacy drivers to xorg-servers conflict array and
remove them from the repo?
Shouldn't we gave them(nvidia) some time to fix this before removing it from
the repo?
Just a thought.
greetings
tpowa
We can always leave the PKGBUILDs in
Roman Kyrylych schrieb:
Correction: the latest openssh package (3.5p1-2)
works around missing /var/empty by creating it in rc.d daemon.
We should do that everywhere when a daemon absolutely needs a
directory/file to exist. We should not rely on it being present on the
file system in such
Aaron Griffin schrieb:
But, if you need anything, I'm fairly certain you guys can handle it.
All of you doing admin type work seem competent enough to deal with
anything that comes up, so I will not have anything to worry about.
Anything except the current hard drive failure, but I guess you
Aaron Griffin schrieb:
On Mon, Nov 2, 2009 at 11:59 AM, Thomas Bächler tho...@archlinux.org wrote:
Aaron Griffin schrieb:
But, if you need anything, I'm fairly certain you guys can handle it.
All of you doing admin type work seem competent enough to deal with
anything that comes up, so I
When I broke our projects.archlinux.org vhost, I noticed that cloning
git via http:// takes ages. This could be vastly improved by running a
regular cronjob to 'git gc' all /srv/projects/git repositories. It would
also speed up cloning/pulling via git://, as the remote: compressing
objects
Dan McGee schrieb:
Realize that this has drawbacks; someone that is fetching (not
cloning) over HTTP will have to redownload the whole pack again and
not just the incremental changeset. You may want something more like
the included script as it gives you the benefits of compressing
objects but
Dan McGee schrieb:
That is the whole point, repack doesn't create small files, it bundles
them up for you. Downloading 3 packs is still quicker than downloading
1 big one if we do it once a week.
I just read the help of repack -d and it totally makes sense to use it
this way. We could
Allan McRae schrieb:
Am Sun, 01 Nov 2009 15:22:19 +1000
schrieb Allan McRae al...@archlinux.org:
Upstream update.
Signoff both,
Allan
This package still has a useless post_install message displayed on each
upgrade. The message suggests that in the case of problems, one should
rebuild
Allan McRae schrieb:
Allan McRae wrote:
I have put the glibc-2.11 toolchain rebuild in [testing]. Apart from
glibc-2.11, the kernel header patch level got bumped to the latest
version and I took a newer snapshot of the binutils-2.20 branch.
From a quick look at the changelog there should
Allan McRae schrieb:
So unless I am missing something, it does not seem entirely wrong.
Anyway, I will remove the install message from SVN so it will not
appear for the next rebuild.
Can I have an i686 signoff now that message is removed from SVN?
Signoff both.
signature.asc
Allan McRae schrieb:
Minor upstream update. Please signoff for both architectures.
Ronald
signoff x86_64
signoff i686
Signoff x86_64.
signature.asc
Description: OpenPGP digital signature
Roman Kyrylych schrieb:
I hit a weird bug.
When my USB 3G modem is plugged in during boot
I get this error for every encrypted partition except /:
Command failed: /dev/mapper/temporary-cryptsetup-1345 open filed: No
such file or directory
When the modem is not plugged during boot everything is
Thomas Bächler schrieb:
Minor upstream update, please sign off. Tested on x86_64 only.
Btw, we should have a fast to core policy for minor kernel updates,
which means they should be signed off within 24 hours - let's try it.
Can we have one more i686?
signature.asc
Description: OpenPGP
NVIDIA released new prereleases of their 173.xx.xx and 96.xx.xx drivers
([1], [2]). Driver packages and kernel modules for the 2.6.31-ARCH
kernel are being uploaded now, they should start to appear on mirrors
soon. Please test them and report.
[1]
501 - 600 of 1431 matches
Mail list logo
