please help me test 2.17

[Tshepang Lekhonkhobe]

I recently uploaded 2.17 to unstable and I want to make sure there are
no obvious issues I can fix before freeze, else we'll be stuck with a
broken wajig in "jessie", or go through the (painful) process of
asking the release team to approve the fix .

Please grab this version and play with it for the next day or two, and
tell me if you see any issues... I did much code cleanup, and as it
happens, I often make mistakes :)

[Reuben Thomas]

Got it, will only report if I find something goes wrong. Sorry I've not found time to look at the bash-completion problem you mentioned, which is still present; I'm very busy at present, but I will look at it when I have time.

--
You received this message because you are subscribed to the Google Groups "wajig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wajig+un...@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at http://groups.google.com/group/wajig.
For more options, visit https://groups.google.com/d/optout.

--
http://rrt.sc3d.org

[Graham Williams]

Thanks. I've installed on all my systems (mostly Ubuntu 14.04). So far so good - I do use update-alternatives.... but probably not for a while. Completion seems to be working just fine.

Graham Williams

http://togaware.com

[Reuben Thomas]

On 24 October 2014 11:55, Graham Williams <Graham....@togaware.com> wrote:

Thanks. I've installed on all my systems (mostly Ubuntu 14.04). So far so good - I do use update-alternatives.... but probably not for a while. Completion seems to be working just fine.

As Tshepang said previously:

I see that "wajig stop "TAB presents wajig sub-commands as completion
entries, instead of installed package names. It's strange because I
don't see a difference between it and "start" and "restart", which all
behave properly. Could you please have a look. The file now lives in
debian/wajig.bash-completion in VCS.

[Graham Williams]

I see what you mean -  very odd. Can't see any reason in that....

Graham Williams

http://togaware.com

--

[luksh...@gmail.com]

Thanks for the great work! Using it to check security/package updates is
part of my daily routine. I pulled the deb-src of 2.17 from unstable and
built it on ubuntu trusty. So far things are working fine.

I played around a bit and found out that "apt-get upgrade" and "wajig
upgrade" behave differently with regards to packages on hold. (Maybe it
has always been like this as I've never tried that before.) Here's the log:

# wajig update
...

# wajig upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
libgts-snapshot : Conflicts: libgts-0.7-5 but
0.7.6+darcs110121-1.1build1 is to be installed
Conflicts: libgts-bin but
0.7.6+darcs110121-1.1build1 is to be installed
libgts-snapshot-dev : Conflicts: libgts-bin but
0.7.6+darcs110121-1.1build1 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
specify a solution).

# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
python-gts
The following packages will be upgraded:
...

"apt-get upgrade" is the correct behaviour for me as I have put a
locally built "python-gts" package on hold. It depends on the locally
built "libgts-snapshot*" packages rather than the "libgts*" packages
provided by ubuntu.

Maybe the different behaviour is due wajig somehow miss the on hold
packages?

Regards,
ST
--

[Tshepang Lekhonkhobe]

When there are upgradable packages, wajig in your case shoould use this command:

/usr/bin/apt-get --show-upgraded --with-new-pkgs upgrade

Can you check if it gives the same result as 'wajig upgrade'?

[luksh...@gmail.com]

Thanks for the explanation. Yes, it does.

If I use "apt-get --show-upgraded upgrade", I get the same (default)
behaviour as "apt-get upgrade".

With "apt-get --with-new-pkgs upgrade", it also tries to install
available newer package(s) which conflicts with the dependency
requirement of the package(s) on hold and therefore it stops (Ie, same
behaviour as "wajig upgrade"). However, the side effect is it prevents
*all* (other) upgrades, including those that are unrelated to the
package(s) on hold. This may not be desirable as security upgrades will
also be blocked.

I would suggest "wajig upgrade" follow the same behaviour as "apt-get
upgrade" to reduce the surprise factor.

Regards,
ST
--

[Tshepang Lekhonkhobe]

Thanks for the analysis, but I think the bug report should go to
apt-get instead. I feel like yours is too much of a corner case to
have to revert back to plain "apt-get upgrade", with its drawback of
keeping some packages un-upgraded.

[luksh...@gmail.com]

On further testing, it seems "wajig fix-missing" behaves in the same way
as "apt-get upgrade", at least as far as on-hold packages are concerned.

BTW, does wajig read and use options in the configuration files of tools
(apt, apt-file, etc) when it makes use of them?

Regards,
ST
--

[Reuben Thomas]

On 6 November 2014 06:28, <luksh...@gmail.com> wrote:

BTW, does wajig read and use options in the configuration files of tools (apt, apt-file, etc) when it makes use of them?

Wajig does not, for the most part, do things itself, it simply runs apt-get, apt-file and the others. So yes, it uses their configuration.

I thought this was obvious (I started using wajig precisely because it would run the various apt commands without my having to remember which one I needed), but maybe it could be made more obvious?

 

--

http://rrt.sc3d.org