Re: Bootloaders BoF at DebConf?

[Joachim Wiedorn]

Hello,

Colin Watson  wrote on 2010-06-21 22:22:

> There've been several bootloader-related threads here of late, and
> grub2, lilo, and syslinux all seem to have fairly active work happening
> on them.  (For all I know the same may be true of some of the
> bootloaders specific to non-x86 architectures too.)  Would it be worth
> having a bootloaders BoF of some kind at DebConf, or maybe some hacking
> sessions?  I'd be curious to know who else would be interested in such a
> thing, and whether there's anything particular that other bootloader
> maintainers would like to discuss, or maybe things that people would
> like to have supported in a bootloader and can come armed with
> specialist knowledge.

Now, I haven't heard more about bootloaders BoF at DebConf. Do you need
some more input about LILO for this BoF?


Have a nice day,

Joachim (Germany)



signature.asc
Description: PGP signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Steve Langasek]

On Thu, Jul 15, 2010 at 09:17:38PM -0700, Russ Allbery wrote:
> > I wouldn't place any of Boost in that category.  In fact, I wouldn't
> > place "aptitude" in that category, either.

> aptitude was historically the recommended tool to use for upgrades because
> it had the best dependency resolver for handling the dist-upgrade case.
> For so long as that's true, it should be priority: important, which means
> that by definition the things that it requires are also priority:
> important or higher.

> If apt-get is now strong enough that we can recommend it for upgrades
> without qualms, then aptitude is another alternative package manager and
> standard may be fine.  Is that now the case?

Not only is apt-get now strong enough to handle the cases for which we
recommended aptitude in the sarge timeframe (with much better resolution of
upgrades, installation of Recommends by default, and tracking of
auto-installed packages), but aptitude has also had several deplorable
regressions since etch.  I don't know which of these made it into the lenny
release or which are still present in squeeze, but:

  - When I type 'aptitude install foo', *removing* foo instead of upgrading
is not a valid solution and should never be offered.
  - When I type 'aptitude install foo', installing 5 packages, removing 3
others, and upgrading 7 more *without installing foo* is not a valid
solution and should never be offered.

And the reason I don't know if these regressions are still present in lenny
or squeeze is that, after about the second time running into such issues, I
abandoned use of aptitude altogether.  It's one thing to be unable to find a
solution and throw me an error; I have no patience for tools that do
something other than what I tell them to.

On Sat, Jul 17, 2010 at 12:43:05AM +0900, Osamu Aoki wrote:

> > Though I think any manual published on debian.org recommending aptitude for
> > upgrades is a bug that should be fixed.

> I fail to understand your intent of this statement.  

> Are you suggesting me to change the following text? 

>   Aptitude is the current preferred package management tool for the
>   Debian system. 

Yes, I believe this text should be changed.

> How does it need to be changed?  I am very curious and open for
> suggestion.

I believe the correct recommendations would be:

  - apt-get for all commandline operations, including package installation
and removal, and dist-upgrades
  - aptitude for an interactive text interface for managing the installed
packages
  - update-manager for keeping your system up-to-date if you're running the
default GNOME desktop.

> Please note this document[1] is claimed to be a secondary documentation.
> I am merely following the primary documentation:
> http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgradingpackages

> | Release Notes for Debian GNU/Linux 5.0 (lenny)
> |
> | 4.5. Upgrading packages
> | 
> | The recommended way to upgrade from previous Debian GNU/Linux releases
> | is to use the package management tool aptitude. This program makes safer
> | decisions about package installations than running apt-get directly. 

> As I recall, there were long active discussion to reach this text.  So
> at least, this assessment is not an opinion of a single developer.

Two things:

 - This is a recommendation to use it as a tool for upgrading from previous
   releases, and is not an endorsement of the tool as a "preferred" package
   manager for other operations.  The upgrade instructions in the release
   notes are carefully crafted to try to smoothly and correctly handle
   upgrades on as many users' systems as possible, and for that reason,
   solutions should be considered for each release that use tools other than
   those recommended for daily operations.

 - The recommendation in the release notes was correct /at the time it was
   drafted/ (i.e., for sarge).  By lenny, it was giving noticeably worse
   results than apt-get in many cases, but by the time the issue was raised,
   some felt it was too late in the release cycle to revisit the text.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Steve Langasek]

On Fri, Jul 16, 2010 at 11:59:45AM +0200, Frans Pop wrote:
> Steve Langasek wrote:
> > This manual represents the opinion of a single developer.

> And what does that have to do with the price of bananas in Iceland?

> The fact that aptitude is currently the recommended tool for package 
> management has various reasons: user interface, features, dependency 
> handling, etc. That status has evolved over the last 3 or so release 
> cycles. You have even been part of some of the discussions (for example 
> sarge -> etch upgrade issues)

"Dependency handing" is certainly not a reason to recommend aptitude.

Yes, I was part of the discussions recommending it for release upgrades in
the sarge and etch timeframe.  For lenny, I strongly counseled *against*
recommending aptitude for release upgrades, due to some concrete regressions
in aptitude's upgrade handling at the same time that apt itself had reached
parity on all the relevant features (improved upgrade resolver; Recommends
handling).  It remained in the release notes anyway owing to concerns that
it was too late in the cycle to get good tester feedback on upgrades using
apt-get, but I intend to again advise removing aptitude from the squeeze
release notes in favor of apt-get.  aptitude's resolver is just too
inconsistent and has too many pathological edge cases for it to be a good
idea to recommend its use as a dist-upgrader.

Now for interactive upgrades, aptitude does have the best interface.  But it
doesn't follow that it should be Priority: important as a result; there are
any number of packages that we may recommend for one purpose or another that
nevertheless shouldn't be installed as 'important'.

> aptitude is the primary tool used by Debian Installer (and because of that 
> its current priority of "important" is actally necessary).

This is the only reason I see that it should be 'important'.  I'm not (yet)
convinced that this is necessary.  Some alternatives would seem to be:

  - opportunistically install aptitude when a user wants fine-grained
package selection in the installer; otherwise only install it when the
'standard' task is selected.  (Downside: user has to wait for aptitude
to be installed, introducing delay at another point in the installer.)
  - have the installer special-case the automatic installation of aptitude in
spite of not being Priority: important, so that it's available at the
right point in the installer. (Downside: special-casing; and if the user
doesn't select the standard task, we either uninstall it at the end of
the install leaving users without access to this interface post-install,
or we leave it on everybody's system anyway, in which case it might as
well just be Priority: important.)

These are some other options to think about, but on balance, I would
conclude that raising the priority of libboost-iostreams to important is
actually the right solution.  Boost is an annoyingly unstable library to
depend on and its library transitions are painful, but most of the
individual component libraries (including libboost-iostreams) are actually
quite small with no unusual dependencies; and raising one of these
components to important shouldn't cause any problems.

> It is also recommended in both the Release Notes (for stable release
> upgrades) and the Installation Guide.

The first of these is a bug that needs fixed.  The second is a reasonable
recommendation if we're pointing users at the TUI; for the CLI we should
simply recommend apt-get.

> So what's listed in the "Debian Reference" is a correct reflection of 
> aptitude's current status and not, as you imply, the result of some single 
> developer being on crack.

Right, it's the result of several developers being on crack. :-P
Regardless of whether there are other developers who agree with this
particular opinion (which, for any given opinion, is bound to be the case),
I think it's important to distinguish between documents whose drafting is
done on open mailing lists and whose recommendations are the result of
consensus (Debian Policy; DevRef, now that it's on debian-policy;
Installation Guide; Release Notes) and those that are maintained by
individuals.  The latter are useful, but are not the word of the Project.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718001852.ga3...@dario.dodds.net

udev: chown of /dev/ppp

[Hans-J. Ullrich]

Hia Marco andf Russell, 

tahnk you very much for your help. Well, I checked out and changed all 
permissions as it should be. The environment is now as follows:

1. /usr/sbin/pppd is now set 0475 with owner root:dip

-rwsr-xr-- 1 root dip 269156 28. Nov 2008  /usr/sbin/pppd 

2. The normal user is added in group "dip" and "dialout"

3. The application /usr/bin/umtsmon is now

-rwsr-xr-- 1 root dip 757636 27. Apr 2009  /usr/bin/umtsmon

So everyone in group "dip" is allowed to start it. This is what I wanted.
But I still got the problem, that it crashes due to access rights, when I 
start it as the normal user. As root everythnbig is working well! 

This error message appears:

/usr/sbin/pppd: using the noauth option requires root privileges

This message was the reason for my very first report. What did I miss? Is there 
something else I should check? 

Please feel free to ask for more information. Besides, I know, umtsmon is 
still not in the debian repository, and the main reason for this is exactly 
the problem I described in the past.

Best regards

Hans







-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007181137.25554.hans.ullr...@loop.de

Re: udev: chown of /dev/ppp

[Russell Coker]

On Sun, 18 Jul 2010, "Hans-J. Ullrich"  wrote:
> /usr/sbin/pppd: using the noauth option requires root privileges
> 
> This message was the reason for my very first report. What did I miss? Is
> there  something else I should check?

The man page gives some information on this.  If that isn't enough then the 
debian-user list should be a useful resource for you.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007181951.59574.russ...@coker.com.au

Re: Aptitude wishlist bug with a package - how to get it merged?

[Henrique de Moraes Holschuh]

On Thu, 08 Jul 2010, Thadeu Lima de Souza Cascardo wrote:
> I've submitted bug 497206 for aptitude with a patch attached almost two
> years ago.  It's a new feature, to allow packages to be grouped by
> source. It's usually easier to upgrade all packages from the same
> source, without having to look for (and sometimes guess) what are the
> other packages from that given source package.

Hmm, wishlist seconded, FWLIW.

Grouping by source package is a feature that would help me when I know
for sure something is broken in unstable and the entire set of binary
packages from the same source needs to be put in hold...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718122354.gc15...@khazad-dum.debian.net

Re: packages being essential but having stuff in /usr/?!

[Henrique de Moraes Holschuh]

On Thu, 15 Jul 2010, Russ Allbery wrote:
> Early system startup (before $remote_fs) is a weird and special
> environment, and most services should just depend on $remote_fs and not
> worry about it.  Normally they have to anyway since the daemon being
> started is in /usr.  Services that do not depend on $remote_fs are
> services that have to be prepared to run in a limited and special
> environment and will require special attention and thought.

Which potentially includes anything hooked to udev.

/usr is NOT guaranteed to be available to anything in /etc/udev/* and
/lib/udev/*, unless some other bondary condition forces the kernel to never
issue a certain event during startup.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718123941.gd15...@khazad-dum.debian.net

Re: packages being essential but having stuff in /usr/?!

[Henrique de Moraes Holschuh]

On Thu, 15 Jul 2010, Christoph Anton Mitterer wrote:
> Is there any policy document or that like,... which mandates:
> a) What is guaranteed to be available in initramfs images?

Not much is guaranteed to be available in initramfs, unless you arranged for
it to be, AFAIK.

> b) What is guaranteed to be available as soon as the root-fs is mounted

Only whatever is in /dev, /lib, /etc, /bin, /sbin.

Fail this, and your package is RC buggy, and not fit for release (in the
grounds that it just plain doesn't work in a supported configuration).  All
policy would have to say in the matter is that we do support /usr outside of
/, if that much.

> c) When (!) it is guaranteed that also /usr/ is there? Is it after
> $remote_fs? Or after mountall-nfs.sh?

$remote_fs.  If NFS /usr is being mounted after $remote_fs is available, it
is a grave bug on the NFS scripts.  Policy doesn't have to mandate this
directly, the definition of $remote_fs already does.

> > Only init scripts that do not depend on $remote_fs have to do this check.
> There are quite a lot...

Anything running from udev that depends on /usr also has to gracefully
handle /usr not being available.  Usually, this means you skip the udev hook
if /usr isn't there, and have an *indepondent* initscript set things up at
the end of the boot process.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718130356.ge15...@khazad-dum.debian.net

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Jonathan Wiltshire]

On Sun, Jul 18, 2010 at 02:38:50AM +0200, Steve Langasek wrote:
> 
>   - When I type 'aptitude install foo', *removing* foo instead of upgrading
> is not a valid solution and should never be offered.

It's still an outstanding (and irritating) bug as late as yesterday's
sid...


-- 
Jonathan Wiltshire

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Re: aptitude (priority important) depends on libboost-iostreams (priority optional)

[Michael Banck]

On Thu, Jul 15, 2010 at 11:13:11PM -0500, Steve M. Robbins wrote:
> So while raising Boost will "solve" the issue, it seems to me to be
> a recipe for runaway priority inflation.
> 
> Is there any central authority to vet priority changes?

Indeed, I think this needs wider attention, next to the
apt-get-vs.-aptitude discussion.

I believe additional Depends on important packages should get proposed
on -devel first, so that people can comment on them and possibly
propose alternatives etc.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100718132042.ga17...@nighthawk.chemicalconnection.dyndns.org

Re: packages being essential but having stuff in /usr/?!

[Henrique de Moraes Holschuh]

On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
> But I think:
> 1) the policy description of essential should be clarified then, as now

Essential means that the *package* essential functionality (not all of its
contents or functionality) has to be available at all times in the lifetime
of the *package*, which is related to it being upgraded/replaced.  It
certainly has nothing to do with the lifetime of the *SYSTEM* runtime.

What the essential functionality of a package is varies with the package,
and it is far more related to the needs of dpkg and a subset of the
maintainer scripts, than anything else.

The people who have to deal with Essential packages are *required* to know
in depth everything Essential really means and why.  Debian Policy doesn't
(and has never) gone into that level of detail, AFAIK.

> it really reads "be available and usable on the system at all times".
> I guess we should at least exclude initramfs from that,... an perhaps
> also all or parts of the boot process.

Unless you propose a *conservative* patch to the policy text through the
proper channels, nobody will care.  It is an old horse, really.

It is not like you have any room to wiggle in these strictly technical
matters, so there is little need for policy to steer things.  If you don't
get it exactly right, things break *badly*... and there is usually very few
ways to get it exactly right.

> Why do I think this is important? Well,... one thing the policy implies
> on essential packages is, that you don't have to depend on them (in
> terms of package dependencies) I guess its logical to conclude that
> one also doesn't have to check for the core stuff like cp/cat/rm... this
> would really clutter many scripts.

If you have ANYTHING hooked to udev or the initscripts/upstart subsystems,
and not depending on $remote_fs, you are *REQUIRED* to know what the hell
you're doing.  It is that simple.

initramfs is probably even more restrictive :)

> But right now one may think that _all_ coreutils packages are guaranteed
> to be always there.

Then, that one is not only not ready yet to deal with early userspace or
udev hooks, which would be the only situation where it would matter.

> 2) Personally, I'd prefer to put some of the current /usr/bin utilities
> from coreutils to /bin, especially [, test, printf ... but actually some
> more...
> I guess this makes /bin not much larger, but would be a nice benefit.

You will have to state strong and specific requirements for every utility
you want to move to /bin or to /sbin.  It won't be done "just in case".  And
it obviously means anything that utility uses (e.g. any libraries, and the
dependencies of these libraries, etc) must also be moved to / (/lib, /sbin,
/bin, /etc...)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718133733.gf15...@khazad-dum.debian.net

Re: packages being essential but having stuff in /usr/?!

[Henrique de Moraes Holschuh]

On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
> Having $remote_fs is a really nice way to secure that /usr/-stuff is
> there (and also other stuff like /var...)

It is the *only* supported way, AFAIK...

> As far as I understand - please correct me if I'm wrong - the root-fs is
> just guaranteed, to have /bin/, /sbin and /lib, right? Neither /var
> nor /opt.
> What about /etc?

> Also, right after the init system starts, neither /proc, nor /dev,
> nor /sys are there, right?

You can assume /etc is available along with the root filesystem (/etc must
be part of /).  However, it will be *read-only*.  Read-write scrach space
goes into /lib/init/rw during early userspace, and it does not even exist
during very early userspace.

/proc, /dev and /sys get mounted VERY early, before / is available in
read-write mode.  This does NOT mean everything you might want in /dev is
already functional, or that every module has already been loaded (and
therefore it is possible that something you might want in /proc or /sys
might not be there yet, if ever).

So, it is "You Must Really Know What You're Doing" land.  Look at the code.
We risk much breakage should docs and reality go out of sync.

And it depends on whether an initramfs did some setup or not.  And if you're
doing *anything* that early, you are to subscribe to the relevant
mailinglists for the initscript subsystems to keep in the loop.

> Would it be a good idea, to add new virtual facilities like $dev, $proc
> or so?

Well, this is stuff that is too fragile.  And stuff will only be on /proc or
/dev AFTER the kernel support is active, which can happen rather later than
you would expect (or much earlier!).

It is best to come up with specific scenarios, and bring these up on the
initscripts subsystem ML.

> That way init-scripts could try to even restrict their dependencies
> more, and don't need to find out the current init script (e.g.
> mountdevsubfs.sh)

Only if it doesn't make things even more uncertain.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718135610.gg15...@khazad-dum.debian.net

Re: packages being essential but having stuff in /usr/?!

[Henrique de Moraes Holschuh]

On Sun, 18 Jul 2010, Henrique de Moraes Holschuh wrote:
> On Fri, 16 Jul 2010, Christoph Anton Mitterer wrote:
> > Having $remote_fs is a really nice way to secure that /usr/-stuff is
> > there (and also other stuff like /var...)
> 
> It is the *only* supported way, AFAIK...

Erk.  Look at $local_fs as well.  I didn't double check if /usr is in
the set required to be local (but AFAIK it is not).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100718140105.gh15...@khazad-dum.debian.net

Bug#589545: ITP: xdot -- interactive viewer for Graphviz dot files

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: xdot
  Version : 0.4
  Upstream Author : Jose Fonseca 
* URL : http://code.google.com/p/jrfonseca/wiki/XDot
* License : LGPL-3+
  Programming Lang: Python
  Description : interactive viewer for Graphviz dot files
xdot is an interactive viewer for graphs written in Graphviz's dot language.
It uses internally the graphviz's xdot output format as an intermediate
format, and PyGTK and Cairo for rendering. xdot can be used either as a
standalone application from command line, or as a library embedded in your
python application.

Features:
* Since it doesn't use bitmaps it is fast and has a small memory footprint.
* Arbitrary zoom.
* Keyboard/mouse navigation.
* Supports events on the nodes with URLs.
* Animated jumping between nodes.
* Highlights node/edge under mouse.

I intend to package this under the Debian Python Applications Team.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


signature.asc
Description: Digital signature

Priority dependence

[Steve M. Robbins]

Hi,

The discussion surrounding why aptitude is priority 'important' [1] is
very enlightening.  Thanks to all contributors.  

With respect to the priority of libboost-iostreams, the consensus
seems to be to raise it.

On Sun, Jul 18, 2010 at 02:18:52AM +0200, Steve Langasek wrote:

> [ ... ] on balance, I would
> conclude that raising the priority of libboost-iostreams to important is
> actually the right solution.

This is due to Debian Policy 2.5:

 Packages must not depend on packages with lower priority values
 (excluding build-time dependencies).  In order to ensure this, the
 priorities of one or more packages may need to be adjusted.

Why is this the policy?  Why does it matter?  Surely installing all
the "important" packages will pull in their dependencies regardless of
the depended-upon package's priority.

Thanks,
-Steve

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588608


signature.asc
Description: Digital signature

Re: Priority dependence

[Russ Allbery]

"Steve M. Robbins"  writes:

> This is due to Debian Policy 2.5:

>  Packages must not depend on packages with lower priority values
>  (excluding build-time dependencies).  In order to ensure this, the
>  priorities of one or more packages may need to be adjusted.

> Why is this the policy?  Why does it matter?  Surely installing all
> the "important" packages will pull in their dependencies regardless of
> the depended-upon package's priority.

Ideally, it would be nice to be able to sort out packages by priority and,
from that, build, say, a CD set of only the important and higher packages
and know that it's self-contained.  In practice, I suspect that we have
enough packages with problems here that you have to compute the dependency
closure anyway, but insofar as priorities are useful for anything, I think
that was the goal.

(It's not clear at this point to me whether priorities are really useful
for anything.)

-- 
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: http://lists.debian.org/87oce4k89b@windlord.stanford.edu

Re: Priority dependence

[Frans Pop]

Steve M. Robbins wrote:
> This is due to Debian Policy 2.5:
> 
> Packages must not depend on packages with lower priority values
> (excluding build-time dependencies).  In order to ensure this, the
> priorities of one or more packages may need to be adjusted.
> 
> Why is this the policy?  Why does it matter?  Surely installing all
> the "important" packages will pull in their dependencies regardless of
> the depended-upon package's priority.

I've been wondering for some time if this policy isn't outdated and should 
maybe be relaxed, at least for library packages.

I suspect the origin of the policy is that in olden days tools like 
debootstrap and debian-cd relied exclusively on priority to get the 
contents of the base system correct. However, for at least the last three 
releases those tools have full dependency resolution support and they will 
correctly pull in any dependencies regardless of priority.

The current policy results in some busy-work for FTP masters who need to 
adjust priorities to comply with this policy. As there is no longer any 
real necessity to have the priorities correct at all times, this is mostly 
left to the final stages of release preparation (unless BRs are filed).

It also frequently results in outdated (ABI versions of) libs being 
included in base installs when no package of high prio depends on a lib 
anymore but the lib's prio has not yet been adjusted downwards.

Maybe we should consider changing the default prio for all library packages 
to optional or lower, except for specific cases (e.g. libc) where the lib 
itself can actually be considered part of the core system.

It's quite possible I'm missing reasons for the existing policy. Maybe 
there are still tools or procedures that rely on matching priorities, 
though I'm not aware of any and I've never heard of anything breaking 
because of the prio mismatches we currently frequently have.

Something to consider for Squeeze + 1?

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007181941.12294.elen...@planet.nl

Re: Priority dependence

[Russ Allbery]

Frans Pop  writes:

> I've been wondering for some time if this policy isn't outdated and
> should maybe be relaxed, at least for library packages.

> I suspect the origin of the policy is that in olden days tools like
> debootstrap and debian-cd relied exclusively on priority to get the
> contents of the base system correct. However, for at least the last
> three releases those tools have full dependency resolution support and
> they will correctly pull in any dependencies regardless of priority.

> The current policy results in some busy-work for FTP masters who need to
> adjust priorities to comply with this policy. As there is no longer any
> real necessity to have the priorities correct at all times, this is
> mostly left to the final stages of release preparation (unless BRs are
> filed).

> It also frequently results in outdated (ABI versions of) libs being
> included in base installs when no package of high prio depends on a lib
> anymore but the lib's prio has not yet been adjusted downwards.

> Maybe we should consider changing the default prio for all library
> packages to optional or lower, except for specific cases (e.g. libc)
> where the lib itself can actually be considered part of the core system.

I would make a stronger argument than that: how much do we care about any
priorities other than important, standard, and everything else?  Do we
really care about the difference between required (insofar as required
means something outside of the essential set) and important, or between
optional and extra, for *any* package?

The one remaining use case for priorities seems to be to be seed material
for installation scenarios.  For that, there seem to be three basic
installation bases that people are likely to want:

* Essential-only, usually only desirable in cases like build chroots.
  Doesn't use priority at all, but should just start from the essential
  packages and compute a dependency closure.  This seems to be what the
  intention of Priority: required was, but I'm not sure I see why we
  should have required separate from Essential: yes plus dependencies.

* Base installation.  The smallest possible installation you can put on a
  regular system and have a working and usable text-mode computer on which
  you can install other things and which looks like UNIX.  This seems to
  be what Priority: important is supposed to give you.

* Standard installation.  This should be chosen explicitly for the
  installer, really.  The difference between Priority: standard and
  Priority: optional-or-extra would be whether we think it makes sense to
  install that package in a default install.

The Policy language around this is written as if installing all of
optional were a reasonable thing to do, which hasn't been the case for
years.

I'm probably on weaker ground in merging required and important, but I'd
like to know more background for why we have these levels and
distinctions.

-- 
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: http://lists.debian.org/87hbjwk6p1@windlord.stanford.edu

Re: Priority dependence

[Frans Pop]

Russ Allbery wrote:
> [...] or between optional and extra, for *any* package?

I must admit that I've never seen the practical value of that distinction.

As to the rest of your message: it certainly seems worth discussing this in 
a bit wider context.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007182030.00628.elen...@planet.nl

Bug#589567: ITP: plasma-widget-adjustableclock -- This plasma widget shows date and time in adjustable format using rich text.

[Davi]

Package: wnpp
Severity: wishlist
Owner: Davi 

* Package name: plasma-widget-adjustableclock
  Version : 2.2-3
  Upstream Author : Alessandro Ghersi 
* URL : 
http://www.kde-look.org/content/show.php/Adjustable+Clock?content=92825
* License : GPL version 2
  Programming Lang: C++
  Description : This plasma widget shows date and time in adjustable format 
using rich text.

This plasma widget shows date and time in adjustable format using rich text.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100718180723.2278.14305.report...@i7.domain.name

Re: Priority dependence

[Neil Williams]

On Sun, 18 Jul 2010 11:04:10 -0700
Russ Allbery  wrote:

> Frans Pop  writes:
> 
> > Maybe we should consider changing the default prio for all library
> > packages to optional or lower, except for specific cases (e.g. libc)
> > where the lib itself can actually be considered part of the core system.
> 
> I would make a stronger argument than that: how much do we care about any
> priorities other than important, standard, and everything else? 

It is very worthwhile having a clear division between Required and
Important. A typical bootstrap should include Required but there is no
need for any of the important packages and any which may be useful can
be added explicitly. Please don't merge Important or lose the
distinction between Required and Important - Required is sufficiently
bloated already without adding Important. Far preferable (from an
embedded perspective) to drop Important and make everything else into a
default Priority (optional).

IMHO There is nothing in Important that deserves bringing in everything
else in Important. i.e. I'd welcome dropping Important, Optional and
Extra completely and only having one default bag for everything not
Priority: required or higher.

> Do we
> really care about the difference between required (insofar as required
> means something outside of the essential set) and important, or between
> optional and extra, for *any* package?

Yes. The difference between required and everything else *is* important
- the distinctions beyond that point are redundant. 
 
> The one remaining use case for priorities seems to be to be seed material
> for installation scenarios.  For that, there seem to be three basic
> installation bases that people are likely to want:
> 
> * Essential-only, usually only desirable in cases like build chroots.
>   Doesn't use priority at all, but should just start from the essential
>   packages and compute a dependency closure.  This seems to be what the
>   intention of Priority: required was, but I'm not sure I see why we
>   should have required separate from Essential: yes plus dependencies.
> 
> * Base installation.  The smallest possible installation you can put on a
>   regular system and have a working and usable text-mode computer on which
>   you can install other things and which looks like UNIX.  This seems to
>   be what Priority: important is supposed to give you.

I disagree, Priority: required is all that is necessary for that
purpose. Important does not constitute a collected set of packages
which all have the same usefulness. Nothing "important" is omitted by
omitting Priority: important in a base installation. Even apt is not
Priority: required and IMHO should not be so.

> I'm probably on weaker ground in merging required and important, but I'd
> like to know more background for why we have these levels and
> distinctions.

I'm away from my usual test installations right now but I am confident
that Important is not as it seems. It is a loose collection of packages
which, individually, are important to many situations but are not
*required* by all. Installing one Important package does not warrant
installing the rest.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp2MVmBZt3yb.pgp
Description: PGP signature

Re: Priority dependence

[Michael Banck]

On Sun, Jul 18, 2010 at 10:14:57PM +0100, Neil Williams wrote:
> On Sun, 18 Jul 2010 11:04:10 -0700
> Russ Allbery  wrote:
> 
> > Frans Pop  writes:
> > 
> > > Maybe we should consider changing the default prio for all library
> > > packages to optional or lower, except for specific cases (e.g. libc)
> > > where the lib itself can actually be considered part of the core system.
> > 
> > I would make a stronger argument than that: how much do we care about any
> > priorities other than important, standard, and everything else? 
> 
> It is very worthwhile having a clear division between Required and
> Important. A typical bootstrap should include Required but there is no
> need for any of the important packages 

If you want to have it minimal, install just the essential packages I
think was Russ' point.  And/or possibly change/adjust essential so that
it matches what you say is required above.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100718220831.ga20...@nighthawk.chemicalconnection.dyndns.org

Re: Priority dependence

[Russ Allbery]

Neil Williams  writes:

> It is very worthwhile having a clear division between Required and
> Important. A typical bootstrap should include Required but there is no
> need for any of the important packages and any which may be useful can
> be added explicitly.

That's probably part of what I'm missing; what's the purpose of required
in addition to essential plus dependencies?

Policy defines required as:

Packages which are necessary for the proper functioning of the system
(usually, this means that dpkg functionality depends on these
packages). Removing a required package may cause your system to become
totally broken and you may not even be able to use dpkg to put things
back, so only do so if you know what you are doing. Systems with only
the required packages are probably unusable, but they do have enough
functionality to allow the sysadmin to boot and install more software.

This sounds quite a bit like the definition of essential, except that
required adds "allow the sysadmin to boot" and essential has the special
unconfigured requirement.

Hm.  So are there packages that aren't usable until configured but which
should never be removed from the system?  I guess that would be the
difference between required and the essential closure.

> Please don't merge Important or lose the distinction between Required
> and Important - Required is sufficiently bloated already without adding
> Important. Far preferable (from an embedded perspective) to drop
> Important and make everything else into a default Priority (optional).

Well, I was asking a question about the goals of the priority levels in
the abstract, not about what's currently classified there.  If we merged
required and important, obviously there's probably a lot of stuff that's
currently in important that should drop back a level to standard.

>> * Base installation.  The smallest possible installation you can put on a
>>   regular system and have a working and usable text-mode computer on which
>>   you can install other things and which looks like UNIX.  This seems to
>>   be what Priority: important is supposed to give you.

> I disagree, Priority: required is all that is necessary for that
> purpose.

You disagree that's what Priority: important is supposed to give you?

Important programs, including those which one would expect to find on
any Unix-like system. If the expectation is that an experienced Unix
person who found it missing would say "What on earth is going on,
where is foo?", it must be an important package. Other packages
without which the system will not run well or be usable must also have
priority important. This does not include Emacs, the X Window System,
TeX or any other large applications. The important packages are just a
bare minimum of commonly-expected and necessary tools.

That sure sounds like what it says.  Or do you think our implementation of
important is buggy?  You're coming across as disagreeing vehemently with
me but being insufficiently clear for me to be able to figure out what
you're actually disagreeing with.  :)

There's an open Policy bug requesting clarification of the difference
between important and standard, and I admit I'm rather fuzzy on that
myself.

-- 
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: http://lists.debian.org/87630cigfi@windlord.stanford.edu

KVM and 2.6.32-5-amd64

[Russell Coker]

I recently tried to start a KVM image with the same script as I had used 
previously.

I had just upgraded the host (which tracks unstable) from 2.6.32-4 to 
2.6.32-5, the virtual machine had been running 2.6.32-5-amd64 for a while (but 
maybe not the very latest version).

The result was that the kvm process went into an infinite loop and the boot 
process stopped at about the stage where the initrd code was due to be run - 
I'm not sure exactly what happened as there wasn't any further output.

When I ran kvm with a 2.6.32-4-amd64 kernel everything worked correctly.

I'm not sure whether this is a bug in the kernel or kvm - maybe bugs in both.  
Any suggestions for what I should do to debug this?

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007190903.07460.russ...@coker.com.au

Bug#589598: ITP: libhibernate-jbosscache -- Java library that provides integration of Hibernate with JBossCache

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: libhibernate-jbosscache
  Version : 3.3.2.GA
  Upstream Author : Red Hat Middleware LLC
* URL : 
http://anonsvn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.2.GA/cache-jbosscache/
* License : LGPL
  Programming Lang: Java
  Description : Java library that provides integration of Hibernate with 
JBossCache

 This Java library provides support in Hibernate
 for JBossCache 1.x APIs.
 . 
 Hibernate is an object-relational mapping (ORM) Java
 library and JBossCache is a replicated cache for
 frequently accessed Java objects in a cluster, in order to
 improve the performance of applications.

This package it is needed because Hibernate 3.5 dropped
support for JBossCache 1.x but JBoss AS 4 depends on that
component.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100719000736.ga25...@miguel.cc

Re: Upstream Tracker

[Erik de Castro Lopo]

Andrey Ponomarenko wrote:

> Hello, Colleagues!
> 
> The new service for tracking ABI changes in various C/C++ libraries is
> now available for Linux distribution maintainers and upstream developers
> - "Upstream Tracker". It may be helpful for analyzing risks of libraries
> updating in the Debian Linux. The service includes more than 100
> libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.
> 
> The service is freely available at:
> http://linuxtesting.org/upstream-tracker/
> 
> Suggestions for libraries inclusion and feature/bug requests are very
> welcome. Thanks!

That is fantastic

I was very pleased to see my libsrary libsndfile up there:

http://linuxtesting.org/upstream-tracker/versions/libsndfile.html

Would also love to see my other library libsamplerate up there:

http://www.mega-nerd.com/libsamplerate/download.html

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100719103459.244dbbe7.mle+deb...@mega-nerd.com

Re: KVM and 2.6.32-5-amd64

[Ben Hutchings]

On Mon, 2010-07-19 at 09:03 +1000, Russell Coker wrote:
> I recently tried to start a KVM image with the same script as I had used 
> previously.
> 
> I had just upgraded the host (which tracks unstable) from 2.6.32-4 to 
> 2.6.32-5, the virtual machine had been running 2.6.32-5-amd64 for a while 
> (but 
> maybe not the very latest version).
> 
> The result was that the kvm process went into an infinite loop and the boot 
> process stopped at about the stage where the initrd code was due to be run - 
> I'm not sure exactly what happened as there wasn't any further output.
> 
> When I ran kvm with a 2.6.32-4-amd64 kernel everything worked correctly.
> 
> I'm not sure whether this is a bug in the kernel or kvm - maybe bugs in both. 
>  
> Any suggestions for what I should do to debug this?

You know we have a BTS, right?  It tracks... bugs... such as #588426.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#589600: ITP: f5vpn-login -- F5 VPN command-line client

[Taku YASUI]

Package: wnpp
Severity: wishlist
Owner: Taku YASUI 


* Package name: f5vpn-login
  Version : 20091224
  Upstream Author : James Y Knight, 
* URL : http://fuhm.net/software/f5vpn-login/
* License : GPL
  Programming Lang: C, Python
  Description : F5 VPN command-line client

 This software allows you to connect to an F5 VPN server without using
 their browser plugin. It also has the advantage of setting up DNS
 properly on OSX systems, which the official client doesn't do. (but
 maybe they will in the future, now that they can copy the method I use).

 It is not supported or affiliated with F5 in any way. I actually find it
 rather sad the client they provide is so terribly poor that I had to
 write this in order to get reliable access to my company's VPN.

 This software does not require any software from F5 to be installed on
 the client. The only requirement is Python 2.3.5 or later. It works on
 at least Linux and OSX systems, but porting to any similar OS should be
 trivial.  Porting to Windows, on the other hand, is probably not
 reasonably possible.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100719012710.7609.29229.report...@falco.local

Re: Last call for keys for keysigning in New York City, USA during DebConf10

[Aníbal Monsalve Salazar]

[Resending as I've had problems posting this message]

As part of the 11th Debian Conference in New York City, USA, there will
be OpenPGP (pgp/gpg) keysignings. If you intend to participate in the
DebConf10 keysignings, please send your ascii armored public key as
explained at [0] no later than Tuesday 20th of July, 2010 at 23:59 UTC.

If your mail to ani...@debian.org cannot get through, send it to anibal
at v7w dot com but first try the debian.org email address please.

More (and up-to-date) information is available at [0], so keep watching
it.

[0] http://people.debian.org/~anibal/ksp-dc10/ksp-dc10.html


About DebConf
-

DebConf is the Debian Project's developer conference. In addition to a
full schedule of technical, social and policy talks, DebConf provides an
opportunity for developers, contributors and other interested people to
meet in person and work together more closely.  It has taken place
annually since 2000 in locations as varied as Canada, Finland, Mexico,
Scotland, Argentina and Spain.

DebConf10 will take place in New York City from Sunday August 1st
through Saturday August 7th.

DebConf will be preceded by DebCamp, from Sunday July 25th through
Saturday July 31st. DebCamp is a smaller, less formal event intended for
group work on Debian projects.

If you or your company are interested in sponsoring DebConf by donating
money or lending equipment, please contact the sponsorship team at
spons...@debconf.org

More information about DebConf10 can be found on the conference website:
https://debconf10.debconf.org/

About Debian


The Debian Project is an association of Free Software developers who
volunteer their time and effort in order to produce an excellent free,
cross-platform operating system.   More information about Debian is
available at http://www.debian.org/

About New York City
---

New York City is the most populous city in the United States.  It spans
five counties, and is the seat of the New York metropolitan area, one of
the most populous urban areas in the world. A leading global city, New
York is a center of worldwide commerce, finance, culture, fashion,
entertainment, international affairs.


signature.asc
Description: Digital signature

Re: i need urgent travel pr1

[j p]

i need seo, web design, logo design, animation, bpo, employment, HR related
sites ...
-- 
Thanking you,
webmaster regards,
seo.jets456 {...@} gmail.com
jets