pacman 4.0.0-2
 

The most anticipated release EVER has landed in [testing]. Do I expect
it to make it out before we need a 4.0.1? Not really. :)

Upstream NEWS/changes:
http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
been actually released.

Questions? Concerns? Comments? I'm telling you as little as possible
about this release and how to make things work to put more people in
the "standard user who doesn't follow development like a hawk" shoes.

This thread is for the *package in testing only*. We have more work to
do from a distro policy standpoint on signing; please do not discuss
that here but in another thread.

-Dan

pacman 4.0.0-2
 

Am 13.10.2011 20:22, schrieb Dan McGee:
> The most anticipated release EVER has landed in [testing]. Do I expect
> it to make it out before we need a 4.0.1? Not really. :)
>
> Upstream NEWS/changes:
> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
> been actually released.
>
> Questions? Concerns? Comments?

Big thanks to everybody involved with this great release. About that
issue I am not supposed to talk here I'll send a mail tomorrow. :-)

Good thing you moved this into testing so there are no excuses not to
test the new pacman. Do you know if porting pyalpm will be easy or is
already done? Would be beter to have this sorted out before moving 4.0
to core. (pyalpm is needed by namcap) I also need to have a look at this
code:
https://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux
But should be easy enough to port if even necessary.

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre

pacman 4.0.0-2
 

On 2011/10/13 Pierre Schmitz <pierre@archlinux.de> wrote:
> Am 13.10.2011 20:22, schrieb Dan McGee:
>> The most anticipated release EVER has landed in [testing]. Do I expect
>> it to make it out before we need a 4.0.1? Not really. :)
>>
>> Upstream NEWS/changes:
>> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
>> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
>> been actually released.
>>
>> Questions? Concerns? Comments?
>
> Big thanks to everybody involved with this great release. About that
> issue I am not supposed to talk here I'll send a mail tomorrow. :-)
>
> Good thing you moved this into testing so there are no excuses not to
> test the new pacman. Do you know if porting pyalpm will be easy or is
> already done? Would be beter to have this sorted out before moving 4.0
> to core. (pyalpm is needed by namcap) I also need to have a look at this
> code:
> https://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux
> But should be easy enough to port if even necessary.

I've followed pacman API changes in pyalpm's trunk all along and will
do the appropriate release asap.

Rémy.

pacman 4.0.0-2
 

On 2011/10/13 Pierre Schmitz <pierre@archlinux.de> wrote:
> Am 13.10.2011 20:22, schrieb Dan McGee:
>> The most anticipated release EVER has landed in [testing]. Do I expect
>> it to make it out before we need a 4.0.1? Not really. :)
>>
>> Upstream NEWS/changes:
>> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
>> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
>> been actually released.
>>
>> Questions? Concerns? Comments?
>
> Big thanks to everybody involved with this great release. About that
> issue I am not supposed to talk here I'll send a mail tomorrow. :-)
>
> Good thing you moved this into testing so there are no excuses not to
> test the new pacman. Do you know if porting pyalpm will be easy or is
> already done? Would be beter to have this sorted out before moving 4.0
> to core. (pyalpm is needed by namcap) I also need to have a look at this
> code:
> https://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux
> But should be easy enough to port if even necessary.

I've followed pacman API changes in pyalpm's trunk all along and will
do the appropriate release asap.

Rémy.

pacman 4.0.0-2
 

On Fri, Oct 14, 2011 at 3:42 AM, Rémy Oudompheng <remy@archlinux.org> wrote:
> On 2011/10/13 Pierre Schmitz <pierre@archlinux.de> wrote:
>> Am 13.10.2011 20:22, schrieb Dan McGee:
>>> The most anticipated release EVER has landed in [testing]. Do I expect
>>> it to make it out before we need a 4.0.1? Not really. :)
>>>
>>> Upstream NEWS/changes:
>>> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
>>> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
>>> been actually released.
>>>
>>> Questions? Concerns? Comments?
>>
>> Big thanks to everybody involved with this great release. About that
>> issue I am not supposed to talk here I'll send a mail tomorrow. :-)
>>
>> Good thing you moved this into testing so there are no excuses not to
>> test the new pacman. Do you know if porting pyalpm will be easy or is
>> already done? Would be beter to have this sorted out before moving 4.0
>> to core. (pyalpm is needed by namcap) I also need to have a look at this
>> code:
>> https://projects.archlinux.org/dbscripts.git/tree/cron-jobs/check_archlinux
>> But should be easy enough to port if even necessary.
>
> I've followed pacman API changes in pyalpm's trunk all along and will
> do the appropriate release asap.
>
> Rémy.
>

Something to note, even though pyalpm is updated to support pacman 4.0
some user intervention would be required, since they'd get this error
on upgrade if they answer Y to the question below:-
:: The following packages should be upgraded first :
pacman
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n]

resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: pyalpm: requires pacman<3.6

Don't think there's a way to deal with that though, either the user
answers 'n' or upgrades pacman with -d? Both are
manual-intervention-required =)

pacman 4.0.0-2
 

Am 13.10.2011 20:22, schrieb Dan McGee:
> The most anticipated release EVER has landed in [testing]. Do I expect
> it to make it out before we need a 4.0.1? Not really. :)
>
> Upstream NEWS/changes:
> http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
> Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
> been actually released.
>
> Questions? Concerns? Comments? I'm telling you as little as possible
> about this release and how to make things work to put more people in
> the "standard user who doesn't follow development like a hawk" shoes.
>
> This thread is for the *package in testing only*. We have more work to
> do from a distro policy standpoint on signing; please do not discuss
> that here but in another thread.
>
> -Dan

I just noticed a somehow unexpected behavior: When I run "pacman -S
devtools" (still had namcap version 3.1) pacman wanted to install these
pacakges:
namcap-3.1-1 pacman-3.5.4-4 pyalpm-0.4.3-1 subversion-1.6.17-6
devtools-0.9.27-1

The thing to notice here is that it didn't warn that pylibalpm requires
pacman 3.5 and that pacman did silently downgrade itself without any
further notice. So in addition to the unexpected downgrade itselfthe
SyncFirst option has no effect in this case?

--
Pierre Schmitz, https://users.archlinux.de/~pierre

pacman 4.0.0-2
 

On 14/10/11 15:10, Pierre Schmitz wrote:

Am 13.10.2011 20:22, schrieb Dan McGee:

The most anticipated release EVER has landed in [testing]. Do I expect
it to make it out before we need a 4.0.1? Not really. :)

Upstream NEWS/changes:
http://projects.archlinux.org/pacman.git/tree/NEWS?h=maint
Disregard the 4.0.1 stuff that isn't in this package yet and hasn't
been actually released.

Questions? Concerns? Comments? I'm telling you as little as possible
about this release and how to make things work to put more people in
the "standard user who doesn't follow development like a hawk" shoes.

This thread is for the *package in testing only*. We have more work to
do from a distro policy standpoint on signing; please do not discuss
that here but in another thread.

-Dan


I just noticed a somehow unexpected behavior: When I run "pacman -S
devtools" (still had namcap version 3.1) pacman wanted to install these
pacakges:
namcap-3.1-1 pacman-3.5.4-4 pyalpm-0.4.3-1 subversion-1.6.17-6
devtools-0.9.27-1


I am majorly confused as why a "pacman -S devtools" would pull
namcap/pyalpm/pacman in if you already had namcap installed and there
are no versioned deps for devtools. I assume you had subversion
installed too...




The thing to notice here is that it didn't warn that pylibalpm requires
pacman 3.5 and that pacman did silently downgrade itself without any
further notice. So in addition to the unexpected downgrade itselfthe
SyncFirst option has no effect in this case?

pacman 4.0.0-2
 

Am 14.10.2011 07:34, schrieb Allan McRae:
> On 14/10/11 15:10, Pierre Schmitz wrote:
>> I just noticed a somehow unexpected behavior: When I run "pacman -S
>> devtools" (still had namcap version 3.1) pacman wanted to install these
>> pacakges:
>> namcap-3.1-1 pacman-3.5.4-4 pyalpm-0.4.3-1 subversion-1.6.17-6
>> devtools-0.9.27-1
>
> I am majorly confused as why a "pacman -S devtools" would pull
> namcap/pyalpm/pacman in if you already had namcap installed and there
> are no versioned deps for devtools. I assume you had subversion
> installed too...

no, here is how I did it: When noticing that pacman wont upgrade due to
pylibalpm being incompatible I removed it with Rcsn which also removed
devtools. The next day I tried pacman -Syu and pacamn -.S devtools which
results in the behavior described.

Also, even after syncing my repo I still had trouble updating. Note
that I had pacman 3.5 and the old pyalpm at this time. As -Syu then
wanted to update pacman first to 4.0 but failed as it did not update
libalpm at the same time. I guess this is a different issue with
SyncFirst. It only updates pacman and its deps but no those packages
that depend on a specific pacman version and therefor fails. I am not
sure if we can solve this issue in a sane way though. At least we should
add this to the announcement that one needs to temporary remove pyalpm
before updating pacman and reinstall it afterwards.

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre

pacman 4.0.0-2
 

On Fri, Oct 14, 2011 at 12:45 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
> Am 14.10.2011 07:34, schrieb Allan McRae:
>> On 14/10/11 15:10, Pierre Schmitz wrote:
>>> I just noticed a somehow unexpected behavior: When I run "pacman -S
>>> devtools" (still had namcap version 3.1) pacman wanted to install these
>>> pacakges:
>>> * namcap-3.1-1 *pacman-3.5.4-4 *pyalpm-0.4.3-1 *subversion-1.6.17-6
>>> devtools-0.9.27-1
>>
>> I am majorly confused as why a "pacman -S devtools" would pull
>> namcap/pyalpm/pacman in if you already had namcap installed and there
>> are no versioned deps for devtools. *I assume you had subversion
>> installed too...
>
> no, here is how I did it: When noticing that pacman wont upgrade due to
> pylibalpm being incompatible I removed it with Rcsn which also removed
> devtools. The next day I tried pacman -Syu and pacamn -.S devtools which
> results in the behavior described.
>
> Also, even after syncing my repo I still had trouble updating. Note
> that I had pacman 3.5 and the old pyalpm at this time. As -Syu then
> wanted to update pacman first to 4.0 but failed as it did not update
> libalpm at the same time. I guess this is a different issue with
> SyncFirst. It only updates pacman and its deps but no those packages
> that depend on a specific pacman version and therefor fails. I am not
> sure if we can solve this issue in a sane way though. At least we should
> add this to the announcement that one needs to temporary remove pyalpm
> before updating pacman and reinstall it afterwards.
Or treat this like any other TODO list and have all the packages ready
to go in [testing], just like it is now.

-Dan

pacman 4.0.0-2
 

Am 14.10.2011 14:43, schrieb Dan McGee:
> On Fri, Oct 14, 2011 at 12:45 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
>> Am 14.10.2011 07:34, schrieb Allan McRae:
>>> On 14/10/11 15:10, Pierre Schmitz wrote:
>>>> I just noticed a somehow unexpected behavior: When I run "pacman -S
>>>> devtools" (still had namcap version 3.1) pacman wanted to install these
>>>> pacakges:
>>>> * namcap-3.1-1 *pacman-3.5.4-4 *pyalpm-0.4.3-1 *subversion-1.6.17-6
>>>> devtools-0.9.27-1
>>>
>>> I am majorly confused as why a "pacman -S devtools" would pull
>>> namcap/pyalpm/pacman in if you already had namcap installed and there
>>> are no versioned deps for devtools. *I assume you had subversion
>>> installed too...
>>
>> no, here is how I did it: When noticing that pacman wont upgrade due to
>> pylibalpm being incompatible I removed it with Rcsn which also removed
>> devtools. The next day I tried pacman -Syu and pacamn -.S devtools which
>> results in the behavior described.
>>
>> Also, even after syncing my repo I still had trouble updating. Note
>> that I had pacman 3.5 and the old pyalpm at this time. As -Syu then
>> wanted to update pacman first to 4.0 but failed as it did not update
>> libalpm at the same time. I guess this is a different issue with
>> SyncFirst. It only updates pacman and its deps but no those packages
>> that depend on a specific pacman version and therefor fails. I am not
>> sure if we can solve this issue in a sane way though. At least we should
>> add this to the announcement that one needs to temporary remove pyalpm
>> before updating pacman and reinstall it afterwards.
> Or treat this like any other TODO list and have all the packages ready
> to go in [testing], just like it is now.

I see my text was probably hard to read, but it was not about some
packages not being updated for pacman 4.0 yet but a possible bug (or
two) in pacman itself.

--
Pierre Schmitz, https://users.archlinux.de/~pierre