On Wed, Jan 19, 2011 at 6:34 PM, Lou wrote:
> ffmpeg-vp8-svn
> http://aur.archlinux.org/packages.php?ID=37297
> Orphan. Does not compile. FFmpeg in extra now has libvpx encoder making
> this package useless.
>
> servicemenu-kvm-kde4
> http://aur.archlinux.org/packages.php?ID=36180
> Orphan. Uses
ffmpeg-vp8-svn
http://aur.archlinux.org/packages.php?ID=37297
Orphan. Does not compile. FFmpeg in extra now has libvpx encoder making
this package useless.
servicemenu-kvm-kde4
http://aur.archlinux.org/packages.php?ID=36180
Orphan. Uses depreciated options that will not work with ffmpeg from
extra
On Wed, Jan 19, 2011 at 6:04 PM, Gergely Imreh wrote:
> Please delete python3-pyke http://aur.archlinux.org/packages.php?ID=45332
> I uploaded a new package, python-pyke to follow the name convention of
> Arch for Python packages.
>
> Cheers,
> Greg
>
Deleted, thanks for the update Greg!
-Tom
Please delete python3-pyke http://aur.archlinux.org/packages.php?ID=45332
I uploaded a new package, python-pyke to follow the name convention of
Arch for Python packages.
Cheers,
Greg
On Wed, Jan 19, 2011 at 4:58 PM, Lukas Fleischer
wrote:
> On Wed, Jan 19, 2011 at 05:53:51PM -0500, jonathan wrote:
> > please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not
> > developing it, and it is redundant to pkgfile.
>
> Done, thanks!
>
It'd be nice to know exactly what
On Wed, Jan 19, 2011 at 05:53:51PM -0500, jonathan wrote:
> please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not
> developing it, and it is redundant to pkgfile.
Done, thanks!
please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not
developing it, and it is redundant to pkgfile.
thanks,
Jonathan "wide-eye'
On Wed, Jan 19, 2011 at 1:15 PM, Kaiting Chen wrote:
> On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif wrote:
>
>> I don't see a need to 'settle' this one. You may not list glibc
>> because it simply makes no sense to not have it at the time of
>> installation. It can be as far deep down as F, but u
On Wed, Jan 19, 2011 at 10:19 AM, Ray Rashif wrote:
> I don't see a need to 'settle' this one. You may not list glibc
> because it simply makes no sense to not have it at the time of
> installation. It can be as far deep down as F, but ultimately it is
> the packagers' (and community's) responsib
On Tue, 18 Jan 2011 19:35:23 -0900 Lou wrote:
> These are all old and orphaned packages that are encoding GUIs to
> ffmpeg.
>
> emoc
> http://aur.archlinux.org/packages.php?ID=34109
> Doesn't work. Just sits there and does not actually convert any
> videos.
Done. (orphan, last update 20100203)
Hi AUR maintainers,
I did a change in the pyqt package to add Python 3 support to it and to allow
everyone to install both the Python2 and the Python3 version.
Every package now need to depends on python2-qt (or python-qt if uses Python
3) instead of pyqt.
The packages in [extra] and [community]
On 19 January 2011 22:23, Stéphane Gaudreault wrote:
> As the maintainer of A, it is not your job to track dependencies of B and D.
>
> Again, look at the problem from a different point of view. If tomorrow
> dependencies of B change to
>
> B -> C F (direct dependecies)
>
> does it mean that A (an
On 20/01/11 00:46, Pierre Chapuis wrote:
Real deps
-
A -> B,D
B -> C
C -> D,E
Current Arch way
A -> B
B -> C
C -> D,E
I think we have established the Transitive closure is impractical, so
lets exclude that.
The "current Arch way" has the advantage of speed in depen
On Wed, Jan 19, 2011 at 14:46, Pierre Chapuis wrote:
> On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae wrote:
>
>> The problem is that the transitive closure can not be assumed to be
>> correct.
>>
>> e.g. At the time A is built:
>>
>> A -> B,C,D,E
>> B -> C,D,E
>> C -> D,E
>>
>> Then B is updat
On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae
wrote:
The problem is that the transitive closure can not be assumed to be
correct.
e.g. At the time A is built:
A -> B,C,D,E
B -> C,D,E
C -> D,E
Then B is updated and
B -> C,D,E,F.
Now the assuming a transitive closure for the dependency
On Wed, Jan 19, 2011 at 13:21, Allan McRae wrote:
> On 19/01/11 23:09, Magnus Therning wrote:
>>
>> On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
>>>
>>> On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRae
wrote:
>
> On 19/01/11 22:20,
Le 19 janvier 2011 09:07:33, Pierre Chapuis a écrit :
> On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
>
> wrote:
> > Huh? How is no dependency checks (-Sd) equivalent to complete
> > dependency checking (-S with a transitive closure of dependencies)?
> > They are polar opposites.
>
> What
On 20/01/11 00:07, Pierre Chapuis wrote:
On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
wrote:
Huh? How is no dependency checks (-Sd) equivalent to complete
dependency checking (-S with a transitive closure of dependencies)?
They are polar opposites.
What I mean is that if a transitive clos
On Wed, Jan 19, 2011 at 2:07 PM, Pierre Chapuis wrote:
>
> Here is an example:
>
> A depends on B and D
> B depends on C
> C depends on D and E
>
> Currently the deps will be:
>
> A -> B,D
> B -> C
> C -> D,E
>
> When installing A, Pacman will:
>
> 1) check deps for A, start installing B and D
> 2
On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae
wrote:
Huh? How is no dependency checks (-Sd) equivalent to complete
dependency checking (-S with a transitive closure of dependencies)?
They are polar opposites.
What I mean is that if a transitive closure of dependencies is
performed at pack
On 19/01/11 23:49, Pierre Chapuis wrote:
On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae
wrote:
Ah... OK. then I don't understand this:
On 19/01/11 22:49, Magnus Therning wrote:
Well, if the creation of the transitive closure of dependencies is
created at package build time, then it can be r
On Wed, 19 Jan 2011 23:19:33 +1000, Allan McRae
wrote:
Ah... OK. then I don't understand this:
On 19/01/11 22:49, Magnus Therning wrote:
Well, if the creation of the transitive closure of dependencies is
created at package build time, then it can be removed from pacman,
that should give a b
Le 19 janvier 2011 08:36:04, Cédric Girard a écrit :
> On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault
>
> > wrote:
> >
> >
> > This gives a simple receipie : When you want to list the dependency fo a
> > package, simply look at what is directly used (for binary it is
> > essentially "read
On Wed, Jan 19, 2011 at 2:30 PM, Stéphane Gaudreault wrote:
>
> This gives a simple receipie : When you want to list the dependency fo a
> package, simply look at what is directly used (for binary it is essentially
> "readelf -d" on the files) and you get the dependency list for your
> package.
>
Le 19 janvier 2011 08:07:00, Allan McRae a écrit :
> On 19/01/11 22:49, Magnus Therning wrote:
> > On Wed, Jan 19, 2011 at 12:50, Allan McRae wrote:
> >> On 19/01/11 22:20, Thomas Bächler wrote:
> >>> Am 19.01.2011 08:08, schrieb Allan McRae:
> If we want to be really pedantic about dependenc
Am 19.01.2011 14:19, schrieb Allan McRae:
> On 19/01/11 23:07, Thomas Bächler wrote:
>> It's the exact opposite. You list all dependencies, and dependencies of
>> dependencies, and ...
>>
>
> Ah... OK. then I don't understand this:
Don't worry, me neither.
signature.asc
Description: OpenPGP d
On 19/01/11 23:09, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRaewrote:
On 19/01/11 22:20, Thomas Bächler wrote:
Am 19.01.2011 08:08, schrieb Allan McRae:
If we want to be
On 19/01/11 23:07, Thomas Bächler wrote:
Am 19.01.2011 14:07, schrieb Allan McRae:
Its has been many years since I did graph theory... but isn't a
"transitive closure" essentially what we have been doing with only
listing the top level of dependencies and having them cover the rest?
It's the e
On Wed, Jan 19, 2011 at 13:07, Allan McRae wrote:
> On 19/01/11 22:49, Magnus Therning wrote:
>>
>> On Wed, Jan 19, 2011 at 12:50, Allan McRae wrote:
>>>
>>> On 19/01/11 22:20, Thomas Bächler wrote:
Am 19.01.2011 08:08, schrieb Allan McRae:
>
> If we want to be really pedantic a
Am 19.01.2011 14:07, schrieb Allan McRae:
> Its has been many years since I did graph theory... but isn't a
> "transitive closure" essentially what we have been doing with only
> listing the top level of dependencies and having them cover the rest?
It's the exact opposite. You list all dependencie
On Wed, Jan 19, 2011 at 10:57 AM, Seblu wrote:
> I just wanted to support your example and suggest to Allan that it
> will be better that Pacman do this job, even if, cost is important.
> IMHO, it's better than pacman take some seconds more to check complex
> dependency, rather than maintenairs do
On 19/01/11 22:49, Magnus Therning wrote:
On Wed, Jan 19, 2011 at 12:50, Allan McRae wrote:
On 19/01/11 22:20, Thomas Bächler wrote:
Am 19.01.2011 08:08, schrieb Allan McRae:
If we want to be really pedantic about dependencies, we should list
_ALL_ dependencies and not remove the ones that
On Wed, Jan 19, 2011 at 1:39 PM, Thomas Bächler wrote:
> Am 19.01.2011 13:32, schrieb Seblu:
>>> If package A depends on package B, and B depends on C, then A might
>>> depend on C explicitly because it accesses C directly. Or it might only
>>> depend on indirectly C because B accesses C. We shoul
On Wed, Jan 19, 2011 at 12:50, Allan McRae wrote:
> On 19/01/11 22:20, Thomas Bächler wrote:
>>
>> Am 19.01.2011 08:08, schrieb Allan McRae:
>>>
>>> If we want to be really pedantic about dependencies, we should list
>>> _ALL_ dependencies and not remove the ones that are dependencies of
>>> depen
On Wed, 19 Jan 2011 13:20:58 +0100
Thomas Bächler wrote:
> Am 19.01.2011 08:08, schrieb Allan McRae:
> > If we want to be really pedantic about dependencies, we should list
> > _ALL_ dependencies and not remove the ones that are dependencies of
> > dependencies.
>
> Why don't we just do the corr
On 19/01/11 22:20, Thomas Bächler wrote:
Am 19.01.2011 08:08, schrieb Allan McRae:
If we want to be really pedantic about dependencies, we should list
_ALL_ dependencies and not remove the ones that are dependencies of
dependencies.
Why don't we just do the correct thing:
If package A depends
Am 19.01.2011 13:32, schrieb Seblu:
>> If package A depends on package B, and B depends on C, then A might
>> depend on C explicitly because it accesses C directly. Or it might only
>> depend on indirectly C because B accesses C. We should reflect that in
>> dependencies (in the first case, A depen
On Wed, Jan 19, 2011 at 1:20 PM, Thomas Bächler wrote:
> Am 19.01.2011 08:08, schrieb Allan McRae:
>> If we want to be really pedantic about dependencies, we should list
>> _ALL_ dependencies and not remove the ones that are dependencies of
>> dependencies.
>
> Why don't we just do the correct thi
Am 19.01.2011 08:08, schrieb Allan McRae:
> If we want to be really pedantic about dependencies, we should list
> _ALL_ dependencies and not remove the ones that are dependencies of
> dependencies.
Why don't we just do the correct thing:
If package A depends on package B, and B depends on C, then
On Wed, 19 Jan 2011 17:08:27 +1000
Allan McRae wrote:
> On 19/01/11 15:19, Kaiting Chen wrote:
> > Okay everyone, every time I ask I get a different answer. According
> > to Dziedzic and Allan 'glibc' does *not* belong in 'depends'. Also
> > Dziedzic votes that *no* package in 'base' should be in
40 matches
Mail list logo