On Tuesday 09 February 2010 08:32:04 Brendan Long wrote:
> On 02/08/2010 07:50 PM, f...@kokkinizita.net wrote:
> > One very simple solution would be to never delete anything
> > named /usr/lib/*.so* unless you really have to. That requires
> > one regexp match. A hack, not perfect but it would help
On Tuesday 09 February 2010 08:35:14 Mauro Santos wrote:
> Currently for my personal use I don't want anything else other than Arch
> but for machines that have more users and _need_ to keep working I'm
> using centos (devs I'm sorry to hinder your world domination plans but I
> think I'm not compe
On Tue, Feb 9, 2010 at 1:49 PM, Eric Bélanger wrote:
> On Mon, Feb 8, 2010 at 8:52 PM, hollunder wrote:
[snip]
>
> As far as mirror are concernced, we (the devs) are aware of the
> problem and knew that the move of the rebuild out of testing would
> create havoc on the mirrors. However, we are wo
> I'm facing a decision to change five 'critical' machines
> in need of an upgrade to Arch or not. Over the last months
> I've installed Arch on three less critical ones to get to
> know the system. Up to yesterday the decision looked quite
> clear
Then maybe you should select something that gives
On 02/08/2010 07:50 PM, f...@kokkinizita.net wrote:
>> It would be interesting to try to patch yaourt to do what you're wanting
>> though. The simplest solution I can think of is some sort of script that
>> finds out which files in a package are libraries (probably something
>> simple like looking
I guess this is not going to change, Fons.
So, may I make one suggestion?
You could create a script to do the following:
1) rsync your /usr/lib to something like /libsforever
2) run pacman with provided arguments from commandline
3) rsync back whats in /libsforever to /usr/lib skipping older fi
On Mon, Feb 08, 2010 at 07:36:55PM -0700, Brendan Long wrote:
> On 02/08/2010 06:46 PM, f...@kokkinizita.net wrote:
> >
> >> It just knows that package (which contains application A0 requires
> >> package libfoo (which contains library libfoo.so.1).
> >>
> > In that case, play it safe and don
On Mon, Feb 8, 2010 at 8:52 PM, hollunder wrote:
> Excerpts from Brendan Long's message of 2010-02-09 02:09:13 +0100:
>> On 02/08/2010 05:50 PM, Allan McRae wrote:
>> > On 09/02/10 10:05, hollunder wrote:
>> >> Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
>> >>> On 09/02/10 04
On 02/08/2010 07:19 PM, Arvid Picciani wrote:
> On Sun, 10 Jan 2010 13:08:10 -0500, Jeff Horelick wrote:
>
>
> if someone actually posts patches or other constructive stuff, please CC
> me. We're rewriting pacman anyway and looking for a solution to handle
> this mess in particular.
>
> Right now
On Tue, Feb 09, 2010 at 02:21:58AM +0100, hollunder wrote:
> Fons ... runs critical systems and had apparently bigger problems.
I should mention that while there have been some problems
I am in general very satisfied with Arch, the documentation
and the support.
The really 'big' problem occured
On 02/08/2010 06:46 PM, f...@kokkinizita.net wrote:
>
>> It just knows that package (which contains application A0 requires
>> package libfoo (which contains library libfoo.so.1).
>>
> In that case, play it safe and don't remove anything that
> any app could depend on. It's better than making
Jörg, it is starting to sound as if you really don't care of distributions ship
cdrtools or not.
And in some cases as it appears from the ubuntu case, you actually "don't want
them to".
They asked for a permission that would allow them to ship your software.
You said no. Care to explain why? Whet
On Sun, 10 Jan 2010 13:08:10 -0500, Jeff Horelick wrote:
if someone actually posts patches or other constructive stuff, please CC
me. We're rewriting pacman anyway and looking for a solution to handle
this mess in particular.
Right now the only idea i got is versioned deps which is sort of flaw
Le Tue, 09 Feb 2010 02:21:58 +0100,
hollunder a écrit :
> Maybe the issues are somewhere else? I don't know. One observation I, as
> a stinking normal user, could make is that there are few devs around
> where users hang out. Let's see.. I know of one dev active in #archlinux
> on IRC and about t
Excerpts from Brendan Long's message of 2010-02-09 02:09:13 +0100:
> On 02/08/2010 05:50 PM, Allan McRae wrote:
> > On 09/02/10 10:05, hollunder wrote:
> >> Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> >>> On 09/02/10 04:49, Xavier Chantry wrote:
> With every big rebuild
On Mon, Feb 08, 2010 at 11:30:39PM -0200, Denis A. Altoé Falqueto wrote:
> On Mon, Feb 8, 2010 at 11:20 PM, wrote:
> > But then: pacman knows that A is installed and
> > depends on libfoo.so.1. But still it removes
> > that library. Why ? I'd just say it fails to
> > do its job, part of which is
On Mon, Feb 8, 2010 at 11:20 PM, wrote:
> But then: pacman knows that A is installed and
> depends on libfoo.so.1. But still it removes
> that library. Why ? I'd just say it fails to
> do its job, part of which is being aware of
> dependencies.
In fact, pacman doesn't know that application A nee
On Mon, Feb 08, 2010 at 05:56:31PM -0700, Brendan Long wrote:
> Why are you even using Arch?
Because it allows me to get recent versions of apps,
it doesn't force me to install a desktop I don't want,
and some other reasons.
> You sound like the kind of person who would want a
> "stable" distro
Excerpts from Allan McRae's message of 2010-02-09 01:50:02 +0100:
> On 09/02/10 10:05, hollunder wrote:
> > Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> >> On 09/02/10 04:49, Xavier Chantry wrote:
> >>> With every big rebuilds we get new breakage stories. It seems like
> >>>
On 02/08/2010 05:36 PM, f...@kokkinizita.net wrote:
He may want *not* to update a particular package
for any good reason (reported regression, adding
unwanted dependencies, user base resistance, ...)
while still wanting to install a new one that
requires a new library version.
The ability to
Le Tue, 09 Feb 2010 09:26:37 +1000,
Allan McRae a écrit :
> So the cause must be... A change in user-base? Maybe just an increase in
> user-base resulting in more people who think Arch should be done their
> way and not the Arch way?
That looks obvious to me. Pacman has been working the same w
On 02/08/2010 05:50 PM, Allan McRae wrote:
On 09/02/10 10:05, hollunder wrote:
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
On 09/02/10 04:49, Xavier Chantry wrote:
With every big rebuilds we get new breakage stories. It seems like
it's the norm nowadays rather than the ex
On Mon, Feb 8, 2010 at 10:54 PM, Denis A. Altoé Falqueto
wrote:
> Just one crazy idea that crossed my mind...
>
> It would be very nice if we could mark some files in a package so that
> when updating the package, they would not be removed and, instead,
> would be added to the list of files belong
On 02/08/2010 04:05 PM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 04:38:46PM -0600, Aaron Griffin wrote:
A package is not a single .so file, unless that is your proposal - to
split all .so files into their own packages.
Here is a list of files that would conflict if this was done
On 02/08/2010 04:49 PM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 06:42:56PM -0500, dave reisner wrote:
On Mon, Feb 8, 2010 at 6:26 PM, wrote:
In other words, do not *force* a user to update all
app using a library just because one of them requires
a newer version. Doing th
On Mon, Feb 8, 2010 at 10:46 PM, Allan McRae wrote:
> I actually do suggest not to use versioned dependencies... that way when
> someone did a "pacman -Sy breakingpkg", it would not pull in the new library
> version and on the new package would be "broken" because of a missing
> library. Version
On 09/02/10 10:36, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 05:06:07PM -0700, Brendan Long wrote:
But wouldn't the optimal solution be doing the depends correctly on
every package, so when your really slow user tries to update
Firefox, it correctly informs them that they need to upda
On 09/02/10 10:05, hollunder wrote:
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
On 09/02/10 04:49, Xavier Chantry wrote:
With every big rebuilds we get new breakage stories. It seems like
it's the norm nowadays rather than the exception.
I am wondering if it's really only
On 09/02/10 10:20, Nagy Gabor wrote:
If I accepted your standpoint as a solution, I would suggest to
not use %CONFLICTS% array or versioned dependencies;-)
I actually do suggest not to use versioned dependencies... that way
when someone did a "pacman -Sy breakingpkg", it would not pull in the
On 09/02/10 09:57, f...@kokkinizita.net wrote:
A binary of an app depends on the*major* version of a
library. Updates that do not change the major version
must be backward compatible.
Hahahahaha... how naive...
Try packaging for a distro for a while and see how that breaks in practice.
On Mon, Feb 08, 2010 at 05:06:07PM -0700, Brendan Long wrote:
> But wouldn't the optimal solution be doing the depends correctly on
> every package, so when your really slow user tries to update
> Firefox, it correctly informs them that they need to update
> everything to do that?
That could plac
On Tue, Feb 09, 2010 at 01:20:15AM +0100, Nagy Gabor wrote:
> Allan McRae wrote:
>
> >So the cause must be... A change in user-base? Maybe just an increase in
> >user-base resulting in more people who think Arch should be done their
> >way and not the Arch way?
>
> Well, I think this viewpoint
The thing is:
1) Since arch is a rolling release, the package of a library is named
such as 'libpng' and not 'libpng-1.1' or 'libpng-1.2', as at any given time
only the latest package should exist in the system.
2) The files and symlinks are created during the package building
process and the pac
On Tue, Feb 09, 2010 at 01:07:18AM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 09:49:50AM +1000, Allan McRae wrote:
>
> > We only support the latest packages in the repos, so if you have
> > issues with old versions of packages or packages from unsupported
> > sources, then it is
On Tue, Feb 9, 2010 at 12:50 AM, Jan de Groot wrote:
> On Mon, 2010-02-08 at 18:52 +0100, Xavier Chantry wrote:
>> It seems the question was not only about kms but also about dri2,
>> which is needed to get 3d support with kms.
>>
>> About nouveau, ums was dropped from ddx on 11th January and
>> e
Allan McRae wrote:
>> With every big rebuilds we get new breakage stories. It seems like
>> it's the norm nowadays rather than the exception.
>>
>> I am wondering if it's really only the users that are to blame.. or if
>> Arch is also to blame. Or if Arch was supposed to be an elitist
>> distributi
Excerpts from Brendan Long's message of 2010-02-09 01:06:07 +0100:
> On 02/08/2010 04:48 PM, Jan de Groot wrote:
> > On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> >
> >> Couldn't the piecemeal update problem be fixed by just putting
> >> version
> >> numbers in the depends() section
On Tue, Feb 09, 2010 at 09:49:50AM +1000, Allan McRae wrote:
> We only support the latest packages in the repos, so if you have
> issues with old versions of packages or packages from unsupported
> sources, then it is up to _you_ to fix them.
I don't have issues with them, except that they get
de
On 02/08/2010 04:48 PM, Jan de Groot wrote:
On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
Couldn't the piecemeal update problem be fixed by just putting
version
numbers in the depends() section in each updated package, so for the
libpng rebuild for example, depends(... libpng>=#.#)?
Excerpts from Allan McRae's message of 2010-02-09 00:26:37 +0100:
> On 09/02/10 04:49, Xavier Chantry wrote:
> > With every big rebuilds we get new breakage stories. It seems like
> > it's the norm nowadays rather than the exception.
> >
> > I am wondering if it's really only the users that are to
On Tue, Feb 09, 2010 at 12:48:21AM +0100, Jan de Groot wrote:
> On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> > Couldn't the piecemeal update problem be fixed by just putting
> > version
> > numbers in the depends() section in each updated package, so for the
> > libpng rebuild for ex
On Mon, Feb 8, 2010 at 9:45 PM, wrote:
> On Mon, Feb 08, 2010 at 05:37:31PM -0600, Aaron Griffin wrote:
>
> > "make install" does it
>
> Called by pacman, I suppose. Anyway this is irrelevant.
>
Two times wrong. It is not called by pacman and it is not irrelevant.
--
Guilherme M. Nogueira
"Any
On Mon, Feb 08, 2010 at 06:42:56PM -0500, dave reisner wrote:
> On Mon, Feb 8, 2010 at 6:26 PM, wrote:
> >
> > In other words, do not *force* a user to update all
> > app using a library just because one of them requires
> > a newer version. Doing this leaves the user with a
> > broken system, pos
On Mon, 2010-02-08 at 18:52 +0100, Xavier Chantry wrote:
> It seems the question was not only about kms but also about dri2,
> which is needed to get 3d support with kms.
>
> About nouveau, ums was dropped from ddx on 11th January and
> extra/xf86-video-nouveau package is from 17th January. So the
On Mon, Feb 08, 2010 at 05:37:31PM -0600, Aaron Griffin wrote:
> "make install" does it
Called by pacman, I suppose. Anyway this is irrelevant.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
On Mon, 2010-02-08 at 13:37 -0700, Brendan Long wrote:
> Couldn't the piecemeal update problem be fixed by just putting
> version
> numbers in the depends() section in each updated package, so for the
> libpng rebuild for example, depends(... libpng>=#.#)? It would fix
> the
> problem in the mos
On 09/02/10 09:26, f...@kokkinizita.net wrote:
On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
I think you miss a point here. After a rebuild NONE of the packages
in the repos depend on the old library. So there is no point in us
packaging the old library for compatibilty, as non
On Tue, Feb 09, 2010 at 12:39:32AM +0100, vlad wrote:
> The idea of a rolling distro also applies to the AUR.
> The AUR as a part of Arch is as "rooling" as Arch is.
> Btw, there are workarounds like "libpng12" in the AUR, if you don't want
> to rebuild all of your own built application.
Again,
> So what ? An update should create/adjust that symlink
> and it currently does. There's no problem with that.
> Just don't delete the old *.so, that's all I ask.
Patch pacman, build your version, and add pacman to IgnorePkg
On Mon, Feb 8, 2010 at 5:39 PM, wrote:
> On Mon, Feb 08, 2010 at 05:37:19PM -0600, Muhammed Uluyol wrote:
>> > So *who* creates the symlink from libfoo.so ->
>> > libfoo.so.1.2.3 ? It's either pacman or ldconfig
>> > called by pacman. Unless you believe in little
>> > gremlins doing it while you
On Mon, Feb 08, 2010 at 05:37:19PM -0600, Muhammed Uluyol wrote:
> > So *who* creates the symlink from libfoo.so ->
> > libfoo.so.1.2.3 ? It's either pacman or ldconfig
> > called by pacman. Unless you believe in little
> > gremlins doing it while you sleep.
>
> It is created 'inside' of the packa
On Mon, Feb 8, 2010 at 6:26 PM, wrote:
>
> In other words, do not *force* a user to update all
> app using a library just because one of them requires
> a newer version. Doing this leaves the user with a
> broken system, possibly at the most inconvenient time.
Arch doesn't force you to update. I
On Tue, Feb 09, 2010 at 12:27:57AM +0100, vlad wrote:
> On Mon, Feb 08, 2010 at 11:54:43PM +0100, f...@kokkinizita.net wrote:
> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> >
> > > you are focusing only on .so which is different but this schema will
> > > work only if the packa
On Tue, Feb 09, 2010 at 12:26:59AM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
>
> > I think you miss a point here. After a rebuild NONE of the packages
> > in the repos depend on the old library. So there is no point in us
> > packaging the
On Mon, Feb 8, 2010 at 5:20 PM, wrote:
> On Mon, Feb 08, 2010 at 05:17:15PM -0600, Aaron Griffin wrote:
>
>> On Mon, Feb 8, 2010 at 4:54 PM, wrote:
>> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>> >
>> >> you are focusing only on .so which is different but this schema will
>>
> So *who* creates the symlink from libfoo.so ->
> libfoo.so.1.2.3 ? It's either pacman or ldconfig
> called by pacman. Unless you believe in little
> gremlins doing it while you sleep.
It is created 'inside' of the package, not during the installation.
$ bsdtar tzf libpng-1.4.0-2-x86_64.pkg.tar.
On Tue, Feb 09, 2010 at 09:18:00AM +1000, Allan McRae wrote:
> I think you miss a point here. After a rebuild NONE of the packages
> in the repos depend on the old library. So there is no point in us
> packaging the old library for compatibilty, as none is needed. We
> only support the latest p
On Mon, Feb 08, 2010 at 11:54:43PM +0100, f...@kokkinizita.net wrote:
> On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>
> > you are focusing only on .so which is different but this schema will
> > work only if the package is split in lib, -dev, whatever as now, the
> > headers will c
On 09/02/10 04:49, Xavier Chantry wrote:
With every big rebuilds we get new breakage stories. It seems like
it's the norm nowadays rather than the exception.
I am wondering if it's really only the users that are to blame.. or if
Arch is also to blame. Or if Arch was supposed to be an elitist
dis
On Mon, Feb 08, 2010 at 05:17:15PM -0600, Aaron Griffin wrote:
> On Mon, Feb 8, 2010 at 4:54 PM, wrote:
> > On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> >
> >> you are focusing only on .so which is different but this schema will
> >> work only if the package is split in lib, -de
On Mon, Feb 08, 2010 at 11:07:41PM +, Pierre Chapuis wrote:
> Le Mon, 8 Feb 2010 23:29:48 +0100,
> f...@kokkinizita.net a écrit :
>
> > *** There is no conflict. *** Pacman can forget
> > about and even delete the package that supplied
> > the old version. It just *should not remove the
> > ol
On 09/02/10 08:54, f...@kokkinizita.net wrote:
On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
you are focusing only on .so which is different but this schema will
work only if the package is split in lib, -dev, whatever as now, the
headers will conflict since it have the same name
On Mon, Feb 8, 2010 at 4:54 PM, wrote:
> On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
>
>> you are focusing only on .so which is different but this schema will
>> work only if the package is split in lib, -dev, whatever as now, the
>> headers will conflict since it have the same na
On Mon, Feb 08, 2010 at 04:38:46PM -0600, Aaron Griffin wrote:
> A package is not a single .so file, unless that is your proposal - to
> split all .so files into their own packages.
>
> Here is a list of files that would conflict if this was done with libpng:
> libpng /usr/bin/libpng-config
> lib
Le Mon, 8 Feb 2010 23:29:48 +0100,
f...@kokkinizita.net a écrit :
> *** There is no conflict. *** Pacman can forget
> about and even delete the package that supplied
> the old version. It just *should not remove the
> old library itself*.
And you end up with .so files not tracked by Pacman in you
http://wiki.archlinux.org/index.php/The_Arch_Way#Code-correctness_over_convenience
On Tue, Feb 09, 2010 at 12:36:55AM +0200, Ionut Biru wrote:
> you are focusing only on .so which is different but this schema will
> work only if the package is split in lib, -dev, whatever as now, the
> headers will conflict since it have the same name on the same
> location.
Not true. When a ne
On Mon, Feb 8, 2010 at 4:29 PM, wrote:
> On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
>
>> When I attempt to install app-baz, which pulls in libfoo 2.0, how do
>> you expect to resolve all the conflicts that result from keeping
>> libfoo 1.0 on the system at the same time as lib
On 02/09/2010 12:29 AM, f...@kokkinizita.net wrote:
On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
When I attempt to install app-baz, which pulls in libfoo 2.0, how do
you expect to resolve all the conflicts that result from keeping
libfoo 1.0 on the system at the same time as l
On Mon, Feb 08, 2010 at 03:47:47PM -0600, Aaron Griffin wrote:
> When I attempt to install app-baz, which pulls in libfoo 2.0, how do
> you expect to resolve all the conflicts that result from keeping
> libfoo 1.0 on the system at the same time as libfoo 2.0? All sorts of
> things are in conflict
Aaron Griffin wrote:
On Mon, Feb 8, 2010 at 3:36 PM, wrote:
On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
It is *required* to do only complete system updates when using Arch.
Partial updates are not supported, *by design*.
If that is true, which I refuse to beli
On Mon, Feb 8, 2010 at 3:36 PM, wrote:
> On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
>
>> It is *required* to do only complete system updates when using Arch.
>> Partial updates are not supported, *by design*.
>
> If that is true, which I refuse to believe, it means
> that Arch is
On Mon, Feb 08, 2010 at 04:19:04PM -0500, Ray Kohler wrote:
> It is *required* to do only complete system updates when using Arch.
> Partial updates are not supported, *by design*.
If that is true, which I refuse to believe, it means
that Arch is a toy system only suitable for kids who
take a kic
On Mon, Feb 8, 2010 at 4:04 PM, wrote:
> If I notice that a new app or an update of an existing one
> has included a new major version of a library, I will in time
> probably update or recompile everything to use the new library
> as well. It would typically be a matter of some days.
>
> Just do
On Tue, Feb 09, 2010 at 03:09:00AM +0800, Ray Rashif wrote:
> I really like the sodepends/soprovides idea, especially after the last
> discussion. After this one, I like it even more. The libfoo2/3/4 has
> always confused me, and is one of the reasons why our repos appear
> "cleaner" and are, in e
On 02/08/2010 11:56 AM, Ray Kohler wrote:
On Mon, Feb 8, 2010 at 1:49 PM, Xavier Chantry wrote:
With every big rebuilds we get new breakage stories. It seems like
it's the norm nowadays rather than the exception.
I am wondering if it's really only the users that are to blame.. or if
Arch i
On 9 February 2010 02:49, Xavier Chantry wrote:
> With every big rebuilds we get new breakage stories. It seems like
> it's the norm nowadays rather than the exception.
>
> I am wondering if it's really only the users that are to blame.. or if
> Arch is also to blame. Or if Arch was supposed to be
Keeping old versions of libs would violate Arch's policy of being bleeding
edge and also complicate things. -1 from me.
On Feb 8, 2010 2:03 PM, "Thomas Bächler" wrote:
Am 08.02.2010 19:56, schrieb Ray Kohler:
> I haven't seen a single reported problem from any of the recent big
> rebuilds that
Am 08.02.2010 19:56, schrieb Ray Kohler:
> I haven't seen a single reported problem from any of the recent big
> rebuilds that wasn't the result of a user doing something they ought
> not to do (usually piecemeal updates), an out-of-sync mirror (plus
> users that can't even recognize this when they
On Mon, Feb 8, 2010 at 1:49 PM, Xavier Chantry wrote:
> With every big rebuilds we get new breakage stories. It seems like
> it's the norm nowadays rather than the exception.
>
> I am wondering if it's really only the users that are to blame.. or if
> Arch is also to blame. Or if Arch was supposed
On Mon, Jan 11, 2010 at 12:53 AM, Aaron Griffin wrote:
> On Sun, Jan 10, 2010 at 12:08 PM, Jeff Horelick wrote:
>> Hey all,
>>
>> I have a suggestion to possibly make rebuilds a bit less painful (or
>> non-existant). I think this is a good idea because it seems like right now,
>> even before ther
On Mon, Feb 8, 2010 at 19:55, solsTiCe d'Hiver
wrote:
> hi.
> i switched to [testing] for some other packages.
> but upon upgrading mkinitcpio, the initramfs (/boot/kernel26.img) has
> not been recreated ?
> is this normal ? expected ? or a bug ?
> will it be upgraded at the next kernel upgrade ?
hi.
i switched to [testing] for some other packages.
but upon upgrading mkinitcpio, the initramfs (/boot/kernel26.img) has
not been recreated ?
is this normal ? expected ? or a bug ?
will it be upgraded at the next kernel upgrade ?
there is no .install file in the mkinitcpio package.
by the way,
On Sat, Feb 6, 2010 at 12:56 PM, Tobias Powalowski wrote:
> It will be supported as .33 will ship kms.
> Right now .32 supports kms for ati and intel cards, nouveau is optional.
>
It seems the question was not only about kms but also about dri2,
which is needed to get 3d support with kms.
About
Xavier Chantry wrote:
> Eben just sent me this summary of his discussion with Jörg Schilling on
> the subject of the cdrtools mkisofs. He said that it can be
> republished/posted anywhere. When/if you do that, please do so *in its
> entirety*. All too easy for things to be taken out of context
On 8 February 2010 10:02, wrote:
> The only alternative to this is making sure that
> updated versions of all apps are made available
> as soon as the new library is used by any of them,
> and this is clearly impossible.
>
> I'm pretty sure that at the moment a system update
> or even complete fr
On 8 February 2010 03:49, wrote:
> On Mon, Feb 08, 2010 at 12:23:28AM -0200, Andre Ramaciotti wrote:
>
>> > Providing only the latest in the repos is OK, but erasing a
>> > previous version **with a different major version number**
>> > on a user's system surely isn't, as existing applications
>>
87 matches
Mail list logo
