Re: aptitude has Priority: standard, why?

[Manuel A. Fernandez Montecelo]

2015-04-01 20:43 The Wanderer:

(Sorry for the delay in replying; I had a response within minutes, but
I've been having bizarre Internet-access issues all day, and I'm not
even sure they're gone yet.)

On 04/01/2015 at 12:02 PM, Peter Samuelson wrote:


[The Wanderer]


it is IMO not viable for actual use - except perhaps by people who
already know completely what they are doing and how to override
aptitude's suggestions.


That sounds like you believe aptitude has only a command-line
interface.


I was indeed only aware of its command-line interface, until just
yesterday; comments in this thread mentioning a "curses interface" led
me to experiment, and discover how to invoke that.

So far as I recall, no documentation or other explanations which I've
ever run across have so much as mentioned this interface, much less
explained how to invoke it or described doing anything through it. The
man page does not mention the term 'curses', and 'interactive' - which
is the only other obvious term I can think of to search for when looking
for something like this mode, even knowing that such a mode exists -
could just as easily describe the "does this dependency solution look
good to you?" mode of operation.

I have yet to do much of anything with that interface, so I'm not
currently competent to speak about it one way or another.


For learning more about the possibilities of aptitude, the user manual is quite
good, actually (with screenshots of different screens, explanations about search
filters, etc).

 http://aptitude.alioth.debian.org/doc/en/

Axel uploaded it there, but you can also install it locally, in english
(aptitude-doc-en) and other languages.



Does aptitude include an equivalently functional analog for
apt-cache?


Well, the things I use most - the 'show' and 'search' functions -
are certainly in aptitude, but apt-cache has a dozen other
subcommands and I don't know whether aptitude implements those in
some way.


If I recall correctly, my original question was about a replacement for
'apt-cache policy', which is about the single most common thing I use
apt-cache for - with show and search being probably second and third
place, respectively. I have been unable to identify any aptitude analog
for that functionality.


The "search" and other commands that accept the same filters and presentation
options (like "versions") allow a very rich query system and possibilities of
customisation in the presentation -- although there are some bugs and not all
fields are implemented/documented (like the URL of the repo).

The examples below show similar info to the "apt-cache policy" mode, in command
line.

(output slightly edited for width and so on)
=

$ apt-cache policy subversion
subversion:
 Installed: 1.8.10-5
 Candidate: 1.8.10-6
 Version table:
   1.8.10-6 0
 500 http://ftp.uk.debian.org/debian/ unstable/main amd64 Packages
  *** 1.8.10-5 0
 100 /var/lib/dpkg/status

=

$ aptitude versions ~n^subversion$
Package subversion:
i   1.8.10-5100
p   1.8.10-6unstable500

Package subversion:i386:
p   1.8.10-6unstable500

=

$ aptitude versions '?name(^subversion$)' -F '%C %A %t %i %p %v %V'
Package subversion:
installed   hold  100  1.8.10-5
purged  hold   unstable   500  1.8.10-6

Package subversion:i386:
purged  none   unstable   500  1.8.10-6
=


I am more fan of the curses interface, though, so I normally use it differently.

What I would do is to fire "aptitude" with no options, press "/" to start
searching, enter "^subversion$" (or same but with "l" to limit/filter the view
to only those matches), press "n" until I find the package that I want among all
matches (mine shows "subversion" and "subversion:i386" for the extra arch, as
above).  Then press "enter" to view the detail of the default version (showing
description etc., and dependencies installed and missing), and if needed go to
the bottom to browse the other available versions with the same package name
(pressing enter here shows the details particular to that version, like
different dependencies).

This is a heavy-handed way of just viewing the available versions and what would
be installed by default, but I would typically be doing other things at the same
time (like selecting a bunch of packages to upgrade, or choosing manually
between the optional or suggested dependencies that I want to install along with
the package).


Hope that helps.
--
Manuel A. Fernandez Montecelo 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https

Re: New system group for Xastir AX.25 users

[Iain R. Learmonth]

Hi Colin,

Thanks for the speedy reply!

On Wed, Apr 01, 2015 at 11:20:43PM +0100, Colin Watson wrote:
> I have no objections to the group handling here.  It sounds as though
> you can and therefore should use a dynamically-allocated group, in which
> case there's no need for any action from me as base-passwd maintainer.

Awesome! Yep, dynamically-allocated group is the plan.

> In fact, I had not realised that policy says that developers should
> contact the base-passwd maintainer in the common case of creating
> dynamically-allocated users or groups.  This doesn't scale terribly
> well, and most developers do not in practice do this, for which I am
> grateful!  Discussion on debian-devel seems reasonable enough as
> technical review, but I can't really imagine the situation where I would
> steer people in the direction of static allocation when it can feasibly
> be avoided.  Would anyone object to me seeking to remove that clause
> from policy ("and checking with the base-passwd maintainer that it is
> unique and that they do not wish you to use a statically allocated id
> instead")?

That seems a sane change to me. If there were going to be updates to the
policy, I would also like to see mention of capabilities and that they
should be preferred over setuid (although falling back is allowed on systems
where capabilities do not work). I may take a look at drafting some changes
regarding that once I've finished my current queue.

Thanks,
Iain.

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: EPVPN 2105
c: 2M0STB  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgp9NZW53O8H4.pgp
Description: PGP signature

Re: New system group for Xastir AX.25 users

[Colin Watson]

On Wed, Apr 01, 2015 at 10:47:18PM +0100, Iain R. Learmonth wrote:
> I am working on the xastir package [1] which is maintained by the Debian
> Hamradio Maintainers team. A wishlist bug has been filed on this package
> (#185915 [2]) requesting the addition of a debconf option to have the binary
> installed setuid to allow for access to the native AX.25 available in Linux.
> 
> According to Debian policy §10.9, the preferred method of doing this is
> through the creation of a group, and users that are allowed to run the
> binary setuid are a member of this group. I also intend to attempt to set
> capabilities first, falling back to setuid if that option is not available.
> 
> The "capabilities first, fall back to setuid" approach is also used by the
> wireshark and iputils packages.
> 
> The same policy section states that the new group name should be discussed
> on debian-devel and with the base-passwd maintainer, and so this email
> serves to start that discussion.
> 
> I propose the group name "xastir-ax25" for this purpose. This uses only
> allowable characters and is 11 characters long (the maximum being 16), and
> so is a valid group name. Are there any objections to this name being used?

I have no objections to the group handling here.  It sounds as though
you can and therefore should use a dynamically-allocated group, in which
case there's no need for any action from me as base-passwd maintainer.

In fact, I had not realised that policy says that developers should
contact the base-passwd maintainer in the common case of creating
dynamically-allocated users or groups.  This doesn't scale terribly
well, and most developers do not in practice do this, for which I am
grateful!  Discussion on debian-devel seems reasonable enough as
technical review, but I can't really imagine the situation where I would
steer people in the direction of static allocation when it can feasibly
be avoided.  Would anyone object to me seeking to remove that clause
from policy ("and checking with the base-passwd maintainer that it is
unique and that they do not wish you to use a statically allocated id
instead")?

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150401222043.gp3...@riva.ucam.org

New system group for Xastir AX.25 users

[Iain R. Learmonth]

Hi,

I am working on the xastir package [1] which is maintained by the Debian
Hamradio Maintainers team. A wishlist bug has been filed on this package
(#185915 [2]) requesting the addition of a debconf option to have the binary
installed setuid to allow for access to the native AX.25 available in Linux.

According to Debian policy §10.9, the preferred method of doing this is
through the creation of a group, and users that are allowed to run the
binary setuid are a member of this group. I also intend to attempt to set
capabilities first, falling back to setuid if that option is not available.

The "capabilities first, fall back to setuid" approach is also used by the
wireshark and iputils packages.

The same policy section states that the new group name should be discussed
on debian-devel and with the base-passwd maintainer, and so this email
serves to start that discussion.

I propose the group name "xastir-ax25" for this purpose. This uses only
allowable characters and is 11 characters long (the maximum being 16), and
so is a valid group name. Are there any objections to this name being used?

Thanks,
Iain.

[1]: https://tracker.debian.org/pkg/xastir
[2]: http://bugs.debian.org/185915

-- 
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: EPVPN 2105
c: 2M0STB  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49


pgpVQ41CsLpa5.pgp
Description: PGP signature

RFS: h5py/2.4.0+dfsg1-1~exp1 -- general-purpose Python interface to hdf5

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal


I am looking for a sponsor for the source package "h5py".

It builds the following binary packages:

 python-h5py  -- Python 2 version
 python3-h5py -- Python 3 version


This upload brings the package up to date with the most recent
stable upstream release.


This package can be checked out at:
 https://anonscm.debian.org/cgit/debian-science/packages/h5py.git

This package can be built with:

 gbp buildpackage --git-debian-branch=debian/experimental \
 --git-upstream-branch=upstream/latest


Changes since the last upload:

  * New upstream release
  * d/control: lintian fix
  * d/copyright:
- lintian fix
- made dep5 compatible
- strip residual .DS_Store files in tarball
  * d/watch:
- add repack due to file strip
  * d/patches/*:
- add 0001-prevent-rpath.patch
- disable drop-mpiposix.patch

Best regards,

Ghislain

Re: aptitude has Priority: standard, why?

[The Wanderer]

(Sorry for the delay in replying; I had a response within minutes, but
I've been having bizarre Internet-access issues all day, and I'm not
even sure they're gone yet.)

On 04/01/2015 at 12:02 PM, Peter Samuelson wrote:

> [The Wanderer]
> 
>> it is IMO not viable for actual use - except perhaps by people who
>> already know completely what they are doing and how to override
>> aptitude's suggestions.
> 
> That sounds like you believe aptitude has only a command-line 
> interface.

I was indeed only aware of its command-line interface, until just
yesterday; comments in this thread mentioning a "curses interface" led
me to experiment, and discover how to invoke that.

So far as I recall, no documentation or other explanations which I've
ever run across have so much as mentioned this interface, much less
explained how to invoke it or described doing anything through it. The
man page does not mention the term 'curses', and 'interactive' - which
is the only other obvious term I can think of to search for when looking
for something like this mode, even knowing that such a mode exists -
could just as easily describe the "does this dependency solution look
good to you?" mode of operation.

I have yet to do much of anything with that interface, so I'm not
currently competent to speak about it one way or another.

>> Does aptitude include an equivalently functional analog for
>> apt-cache?
> 
> Well, the things I use most - the 'show' and 'search' functions -
> are certainly in aptitude, but apt-cache has a dozen other
> subcommands and I don't know whether aptitude implements those in
> some way.

If I recall correctly, my original question was about a replacement for
'apt-cache policy', which is about the single most common thing I use
apt-cache for - with show and search being probably second and third
place, respectively. I have been unable to identify any aptitude analog
for that functionality.

>> I'd been told that apt-get was deprecated in favor of aptitude and
>> I'd seen that aptitude did not seem to have equivalents for the
>> apt-cache commands.
> 
> Deprecating /usr/bin/apt-get is not the same as deprecating the
> whole apt package, including /usr/bin/apt-cache.  If anyone said the
> entire apt package was deprecated, I think they were misinformed.

Having thought on it further, I believe what I'd actually been told at
the time was that apt-get (or some other term, referring to that entire
collection of tools) was no longer maintained and/or no longer
developed, and that any new features etc. would go exclusively into
aptitude, and that using apt-* was therefore not recommended.

This would have been... sometime prior to either lenny or etch, I don't
recall which.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: aptitude has Priority: standard, why?

[Russ Allbery]

The Wanderer  writes:

> I remember, years ago, I asked on some Debian list what the intended
> replacement for apt-cache was, since I'd been told that apt-get was
> deprecated in favor of aptitude and I'd seen that aptitude did not seem
> to have equivalents for the apt-cache commands.

For a while, we were recommending people use aptitude for upgrades instead
of apt-get because the dependency resolver did a better job.  That's
probably where the "deprecated" part came from, as that recommendation did
get reported that way.

However, time marches on, and the apt-get resolver has gotten better.

I think both programs have their place.  Personally, I'd recommend the apt
tool for command-line package installation because I think its defaults
are safer and less confusing.  But it has no equivalent to aptitude for a
curses-based examination of the packages on the system and new packages
now available, which is a rather nice feature.

In terms of dependency resolvers, I think a reasonably fair way to
characterize them is that apt-get errs on the side of caution and can
default to refusing to do anything, whereas aptitude tries a lot harder to
find a dependency solution that changes the system at the cost of
generating a lot of bogus solutions.

My personal experience is that, when I have a difficult or complex
dependency issue on a system, the *second* solution offered by aptitude is
usually better than the only solution offered by apt-get (mostly because
apt-get usually gives up), but the *first* solution offered by aptitude is
usually awful and sometimes actually destructive.  I always found that
pattern strange and kind of amusing, but it's surprising how reliable "run
aptitude and take the second thing it suggests" is in resolving weird
dependency problems.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tk3eqa5@hope.eyrie.org

Re: aptitude has Priority: standard, why?

[Peter Samuelson]

[The Wanderer]
> it is IMO not viable for actual use - except perhaps by people who
> already know completely what they are doing and how to override
> aptitude's suggestions.

That sounds like you believe aptitude has only a command-line
interface.  Mostly I use its full-screen interface.  (To see this
interface, launch it with no arguments.)  What would you suggest as a
replacement for that?  dselect?  I did use dselect for many years, only
reluctantly switching to aptitude, but I have no desire to go back.

> Does aptitude include an equivalently functional analog for apt-cache?

Well, the things I use most - the 'show' and 'search' functions - are
certainly in aptitude, but apt-cache has a dozen other subcommands and
I don't know whether aptitude implements those in some way.

> I'd been told that apt-get was deprecated in favor of aptitude and
> I'd seen that aptitude did not seem to have equivalents for the
> apt-cache commands.

Deprecating /usr/bin/apt-get is not the same as deprecating the whole
apt package, including /usr/bin/apt-cache.  If anyone said the entire
apt package was deprecated, I think they were misinformed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150401160242.ga4...@p12n.org

Bug#781655: ITP: cpl-plugin-naco -- ESO data reduction pipeline for the NACO instrument

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org

* Package name: cpl-plugin-naco
  Version : 4.4.0
  Upstream Author : Yves Jung 
* URL : http://www.eso.org/sci/software/pipelines/naco
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline for the NaCo instrument

This is the data reduction pipeline for the NaCo instrument of the
Very Large Telescope (VLT) from the European Southern Observatory (ESO).
.
NaCo is short for NAOS-CONICA.  It was installed at the Nasmyth B focus
of UT4 from 2001 through 2013.  In 2014 it was reinstalled on UT1 at
the Nasmyth A.  It provides adaptive optics assisted imaging, imaging
polarimetry, coronography and spectroscopy, in the 1-5 micron range.

The package will be maintained within the debian-astro team. A git
repository is set up at 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551bc3c4.9080...@debian.org