RE: font policy changes

[unifoundry]

>  Original Message 
> Subject: Re: font policy changes
> From: Russ Allbery <[EMAIL PROTECTED]>
> Date: Sun, July 13, 2008 10:13 pm
> To: [EMAIL PROTECTED]
> Cc: debian-devel@lists.debian.org, [EMAIL PROTECTED], 
> "Anthony Fok" <[EMAIL PROTECTED]>
>
> [EMAIL PROTECTED] writes:
>
> > 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> > "update-fonts-dir" an absolute path (in which case its man page needs to
> > be updated and the warning removed), isn't it also advisable to run
> > "xset fp rehash" in postinst and postrm scripts? That program is the
> > standard mechanism for updating installed fonts on recent versions of
> > X11, including in Debian and other GNU/Linux distributions.
>
> Hm. That's an interesting thought, although it's going to fail if no X
> server is currently running, correct?
>
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 

True.  I guess that would have to be trapped gracefully.

Would running "fc-cache -f" be preferable?  It will identify bitmap and
TrueType fonts.  There are two things I don't like about that command
though: 1) it has no man page (I guess I can write one) although
"fc-cache --help" lists options; 2) I don't think it dies gracefully --
it can corrupt a cache if there is an error, and doesn't unwind to the
old cache version (unless the program has been improved recently).  Is
that tolerable?


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: font policy changes

[Russ Allbery]

[EMAIL PROTECTED] writes:

> 3) Even if "mkfontdir" were invoked directly or if it's okay to give
> "update-fonts-dir" an absolute path (in which case its man page needs to
> be updated and the warning removed), isn't it also advisable to run
> "xset fp rehash" in postinst and postrm scripts?  That program is the
> standard mechanism for updating installed fonts on recent versions of
> X11, including in Debian and other GNU/Linux distributions.

Hm.  That's an interesting thought, although it's going to fail if no X
server is currently running, correct?

> 5) If I wanted to have symbolic links checked with dh_link, what is the
> preferred way to enter an absolute path to your current location in the
> file?  Should I "just know" that the path will be
> "/usr/share//", or will putting "$(CURDIR)/file.extension"
> work in the debian/.links file, or is there some other
> preferred method?

You should provide the full path of the target file to dh_link.  dh_link
will then do whatever is necessary to make it a Policy-compliant link.  So
if you're linking to a file in /usr/share/, the source should
start with that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

font policy changes

[unifoundry]

I am wrapping up the Debian packages (font + sources + binary utilities
package) for the GNU Unifont.  I believe that some things in the Debian
Policy Manual version 3.8.0.1, 2008-06-05, concerning fonts are
outdated.  Comments and suggestions are welcome.  I'm running the stable
Etch 4.0r3 release.

1) Section 11.8.5, Packages providing fonts, specifies running
"update-fonts-dir".  The man page for this command further specifies
that it should only be given the last directory in a path for a newly
added font.  For example, if a font was just added to the X11 100dpi
directory, then it is only proper to run "update-fonts-dir 100dpi"
rather than give the full pathname to the fonts directory.  This utility
then searches in /usr/lib/X11/fonts.  That directory is deprecated on
Debian.  Debian X11 fonts now appear under /usr/share/fonts/X11.  The
wrong directory is searched even with "update-fonts-dir -7" or
"update-fonts-dir --x11r7-layout" -- the man page says those options
will search in /usr/share/fonts/X11.  This looks like a bug.

2) If, to get around this, "update-fonts-dir" is given an absolute path,
it complains that it was given an absolute path.

3) Even if "mkfontdir" were invoked directly or if it's okay to give
"update-fonts-dir" an absolute path (in which case its man page needs to
be updated and the warning removed), isn't it also advisable to run
"xset fp rehash" in postinst and postrm scripts?  That program is the
standard mechanism for updating installed fonts on recent versions of
X11, including in Debian and other GNU/Linux distributions.

4) What are the preferred steps for registering a TrueType font in
Debian?  It is outside the X11 directory structure, and depends on the
TrueType font server.  GNOME recognizes a newly installed TrueType font
but is there anything that should appear in a postinst or postrm script?

5) If I wanted to have symbolic links checked with dh_link, what is the
preferred way to enter an absolute path to your current location in the
file?  Should I "just know" that the path will be
"/usr/share//", or will putting "$(CURDIR)/file.extension"
work in the debian/.links file, or is there some other
preferred method?  Right now I'm not using dh_link; I'm creating
symlinks with absolute paths in a Makefile using $(CURDIR).

Thanks for any advice.


Paul Hardy
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: Java (JAR) desktop integration/admin tool

[Paul Wise]

On Sun, Jul 13, 2008 at 10:31 PM, RalfGesellensetter <[EMAIL PROTECTED]> wrote:

> - place all jar files to /usr/share/java or /usr/lib/jar

Locally installed and built stuff should go to /usr/local or /opt
rather than there.

> - register desktop relevant jar files in /etc/debian-desktop-jar.conf

Just altering all the menu files that packages put in /etc/xdg/menus/
to look for .desktop files in /usr/local/share/applications should be
the right way.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Changes detected by lintian on rebuilt packages

[Luk Claes]

Raphael Geissert wrote:
> Hi all,

Hi

> * MBF based on the issues found (when lintian reports more issues on the 
> rebuilt package) [1] .

No

MBF shouldn't be done for lintian warnings/errors unless the particular
warning/error is discussed on d-devel and the consensus is that it's
worth to MBF for...

> * Trigger binNMU's for the affected packages (when lintian reports less 
> issues 
> on the rebuilt package) [2].

No, we are not going to binNMU to get less lintian warnings/errors
unless you could convince us it's worth it for particular classes of
problems.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#490702: ITP: pencil -- Traditional animation/drawing software

[Cyril Brulebois]

Janne Jokitalo <[EMAIL PROTECTED]> (13/07/2008):
> I wouldn't mind that at all, and you are correct that it would be my
> first package. I have uploaded a candidate into REVU for including it
> in Ubuntu, so if you don't mind, I would like to upload a candidate
> for Debian after one round of quality assurance. :) Does that suit
> your process?

Sure. As said on IRC, uploads of the source package to any server (be
it mentors.debian.net, your public_html space on alioth, or others) is
OK. We can also drop d-d@ from Cc for further communication. :)

I subscribed to your ITP bug, so I shouldn't miss anything anyway.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#490702: ITP: pencil -- Traditional animation/drawing software

[Janne Jokitalo]

On Sun, Jul 13, 2008 at 09:25:55PM +0200, Cyril Brulebois wrote:
> Hi Janne,

Hello Cyril!

> > Pencil is an animation/drawing software for Mac OS X, Windows, and
> > Linux.
> 
> unsure the platforms are relevant in the Debian long description of the
> package.

Yes of course, it got copied from the homepage of the project directly. I will
remove unrelated platforms.

> > Pencil is free and open source.
> 
> unsure it's needed in the description of a package belonging to main.

That is true also. Will get rid of it as well.

> Besides that, I'd be happy to help you with this package if you need (it
> looks like it might be your first package), be it for comaintenance or
> for sponsorship.

I wouldn't mind that at all, and you are correct that it would be my first
package. I have uploaded a candidate into REVU for including it in Ubuntu, so if
you don't mind, I would like to upload a candidate for Debian after one round of
quality assurance. :) Does that suit your process?

Thank you very much for a quick response and the generous offer! It made me very
glad to see a sponsoring offer already! :)


Best regards,

Jaska


-- 
Janne Jokitalo

astraljava on irc.debian.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Changes detected by lintian on rebuilt packages

[Russ Allbery]

Raphael Geissert <[EMAIL PROTECTED]> writes:

> Because some packages FTBFS, there are some missing build logs[3], and
> because there are some manpage warnings that are/not found either on
> lintian.d.o's results or the archive rebuild's results I can't even
> estimate the number of affected packages.

Man page warnings unfortunately depend on the version of man that you have
installed.  lintian.d.o's results therefore miss quite a few warnings,
since lintian.d.o runs on stable and the man version there is too old to
be able to meaningfully diagnose many problems.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Avoiding misconceptions about Etch+1/2... (was: Debian release versioning)

[Frans Pop]

Russ Allbery wrote:
> To me, this argues for continuing to use 5.0r1, 5.0r2, and so forth for
> stable updates and using 5.1 for the -and-a-half release, with 5.1r1,
> 5.1r2, and so forth for additional stable releases based on it.  That
> means we'd probably never use 5.2, but it follows the versioning that
> makes sense for CD-ROM vendors.  The -and-a-half release *does* make
> their CDs potentially out of date since the -and-a-half release may be
> able to install on hardware that the original release can't.

This isn't quite true. The normal CD sets that will be released with 
etch+1/2 still just use 2.6.18 and install 2.6.18. The basic requirement 
behind Etch+1/2 was after all that stable should remain stable. That's 
what users expect of us. Etch+1/2 is an _option_.

It is *only* when you either
1) manually upgrade the kernel to 2.6.24 _after_ installation, or
2) use any of several "special" installation options that both use
   and install .24
that you actually "get" etch+1/2. A "normal" installation of Etch after 
the next stable release essentially still just gets you 4.0r4.

This is slightly less true if you look at the for the "compatibility with 
2.6.24" updates and new X.Org drivers that have been accepted in 
proposed-updates for etch+1/2, but the essence of etch+1/2 is the newer 
kernel.

So from that PoV the regular CD sets for 4.0r4 will still really just be 
4.0r4, and only those "special" installation options could actually be 
classified as 4.1r0. I'm not sure that is sufficient to hang a new 
version on...


To clarify. The "special" installation options are:
1) using the "etch+1/2 netinst CD": this is the only real etch+1/2
   installer as it contains the Lenny D-I + stable base system
2) using the "lenny beta2 businesscard CD" and boot with 'suite=etch':
   this can also be done now, but it won't yet have the 2.6.24 kernel
   available, so would currently just install 2.6.18; after etch+1/2
   is released and 2.6.24 kernels are in the stable archive, it will
   automatically use those during base system installation
3) using a "lenny beta2 netboot" image: essentially the same story as
   for 2, except that additional D-I components are loaded from a mirror
   (testing) rather than from the CD

The netinst image (option 1) can optionally be used as "CD0" of the 4.0r4 
full CD/DVD sets: you boot of CD0 and, after base-installation, you also 
scan CD1-CDx (or DVD or the KDE/Xfce CDs). The option to scan and use 
multiple CD/DVDs _during_ the D-I installation is new in Lenny.

Even better, you don't even strictly need the 4.0r4 CD set. You could just 
as easily install from the etch+1/2 netinst + any number of CDs from the 
4.0r0 set + a mirror to get etch+1/2...

We have chosen this system for the following reasons:
1) it keeps 2.6.18 as the normal kernel and thus keeps stable==stable
2) it avoids having to build 2 full sets of CD/DVDs which would seriously
   overflow our CD mirroring capacity
3) it avoids CD-vendors suddenly having to create loads of extra options
   on their websites; instead they can just add the netinst CD as a
   "bonus" to the sets they already have
4) it avoids having to create a full branch of D-I just for Etch+1/2
   (which would be more work than anyone would want to do and would
   probably require infrastructure changes that FTP-masters would not have
   been happy with)

Hope this explains.

Cheers,
FJP


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

Re: Changes detected by lintian on rebuilt packages

[Lucas Nussbaum]

On 12/07/08 at 18:50 -0500, Raphael Geissert wrote:
> Because some packages FTBFS, there are some missing build logs[3], and
> because there are some manpage warnings that are/not found either on
> lintian.d.o's results or the archive rebuild's results I can't even
> estimate the number of affected packages.
> 
> [3] At least aboot's is missing, already notified Lucas.

aboot is listed in Packages-arch-specific[1] as being for alpha only, so
I'm not trying to build it.

Some other packages might be missing, because:
- they FTBFS
- their build time out, so they are excluded from my rebuilds
- they are listed in P-a-s as not for i386
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Opposed (Re: Debian release versioning)

[Filipus Klutiero]

I was in favour at first sight, but not anymore. I agree with Adeodato 
that in general, the second integer of a software version is more 
meaningful that a stable update means. Also, as he wrote, it used to 
mean something entirely different in Debian itself, less than 4 years ago.


But at least equally importantly, a stable update is not really a new 
Debian version. When you're running software foo version X.Y and X.Y+1 
comes out, you'd expect to have an update to do. This is generally not 
the case with Debian, or it shouldn't. "stable" rather evolves 
progressively, and a machine updating regularly may see no update or new 
package in a stable update. The main meaning of a stable update is that 
installation media is updated. This is quite similar to d-i releases, 
which aren't reflected in debian_version.


So, I think the Debian version should be simply X. Installation media 
should reflect the build, with something appended to the Debian version, 
similar to how it's done now. Maybe "Debian 6 image build X"? revision 
is not too clear, but I'm not sure how it could be improved. This is 
basically what we're already doing, except the ".0" is dropped. The only 
disadvantage with keeping ".0" is that some users will wonder what it 
means. Perhaps lenny+1 will be announced as "Debian 6".



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Call for testing: mantis Debian package

[Patrick Schoenfeld]

Hi people,

for several reasons Debian Etch did not include a mantis package, which
was sad for the mantis users out there. This will change with lenny and
if everythings works out well Debian Lenny will ship with mantis 1.1.2.
The mantis developers and I worked hard to make this possible, so there
is really an ambition to make this mantis package a really stable one.
To achieve this goal I would need some broader testing and so I hereby
ask for testing. Everything needs to be tested: From new installations
to upgrades, so everybody who wants, can help with testing.

If you want to help you can get the mantis package from here [1].
Before you install it, you will need to fulfill the depends:

aptitude install apache2 libapache2-mod-php5 libphp-adodb libphp-phpmailer ucf \
php5-mysql mysqlclient dbconfig-common

If you need an extra mysql database (e.g. because you don't have a
running one), then please add mysql-server to the depends.

If you are upgrading, you can obvious skip this skep. But you really
should make a backup of your mantis database or even better: Test this
on a different machine.

After this and after you downloaded the mantis*.deb file, you can
install the package, by just using dpkg -i:

dpkg -i mantis_1.1.2+dfsg-1_all.deb

The debconf part of the package should help you to get the database
setup. After this mantis will be available on

http:///mantis

Please test everything you like and report every trouble you have.

It would be good to receive feedback within the next 14 days, otherwise
its unlikely that fixes can still go into lenny. :(

For upgraders:
Its especially important to see if the upgrade works and if there are
charset problems after upgrade, so please test it with your real data
(and configuration) on a second system or so.

If you have any questions feel free to reply to me off-list.

Thanks for your help in advance!

Best Regards,

Patrick
Debian maintainer of mantis

[1]
http://ftp.debian.org/debian/pool/main/m/mantis/mantis_1.1.2+dfsg-1_all.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490707: ITP: socnetv -- social network analysis and visualisation application

[Serafeim Zanikolas]

Package: wnpp
Severity: wishlist
Owner: Serafeim Zanikolas <[EMAIL PROTECTED]>

* Package name: socnetv
  Version : 0.44
  Upstream Author : Dimitris Kalamaras <[EMAIL PROTECTED]>
* URL : http://socnetv.sf.net
* License : GPL
  Programming Lang: C++
  Description : social network analysis and visualisation application

 SocNetV is a graphical application designed to be an easy tool for Social
 Networks Analysis and Visualisation (not to be confused with social
 networking, as in online communities). With it, you can load and visualise
 networks of various formats (GraphViz,Adjacency, Pajek, etc), and/or visually
 create and modify a network using your mouse.
 .
 The program can also compute network statistics and properties, such as
 distances, centralities, diameter etc, and apply some layout algorithms for
 more meaningful visualisation of your networks. Furthermore, it can create
 simple random networks (lattice, same degree, etc).

socnetv is nowhere near complete but with active upstream, so I'll be
packaging this for experimental.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490705: ITP: rakarrack -- Guitar FX processor

[Janne Jokitalo]

Package: wnpp
Severity: wishlist
Owner: Janne Jokitalo <[EMAIL PROTECTED]>


* Package name: rakarrack
  Version : 0.2.0
  Upstream Author : Josep Andreu <[EMAIL PROTECTED]> Daniel Vidal 
<[EMAIL PROTECTED]> Hernán Ordiales<[EMAIL PROTECTED]>
* URL : http://rakarrack.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : Guitar FX processor

Rakarrack is a JACK guitar effects processor emulator. Currently you can use 
following effects: Lineal 
and Parametric EQ, Distortion, Overdrive, Echo, Chorus, Flanger, Phaser, 
Compressor, Reverb, WahWah, 
Alienwah, NoiseGate, Harmonizer, Musical Delay, Pan, Cabinet. It also has 
built-in tuner and MIDI 
Converter.
Rakarrack is under rapid development currently, so please check up their 
homepage 
 regularly, if you want newer versions and 
are not afraid to compile 
it yourself.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[Guido Trotter]

On Sat, Jul 12, 2008 at 06:01:30PM -0700, Steve Langasek wrote:

Hi,

> The distro used on dom0 is pretty uninteresting, given that part of the
> point of having Xen-style virtualization for servers is to a) be able to run
> different OSes in different guests, and b) not to run services in dom0.[1]
> 

Agreed, we shouldn't support arbitrary dom0s, but it would be nice to have one
supported way to run dom0 in debian, be it etch or lenny... If we say "run dom0
in etch" at least can we have the limited etch needed for a dom0 to work blessed
with an extended support, if not support 2.6.18 in lenny?

Thanks,

Guido


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#490702: ITP: pencil -- Traditional animation/drawing software

[Cyril Brulebois]

Janne Jokitalo <[EMAIL PROTECTED]> (13/07/2008):
> * Package name: pencil
>   Version : 0.4.4b
>   Upstream Author : Pascal Naidon <[EMAIL PROTECTED]> Patrick Corrieri 
> <[EMAIL PROTECTED]>
> * URL : http://www.les-stooges.org/pascal/pencil/
> * License : GPL
>   Programming Lang: C++
>   Description : Traditional animation/drawing software

Hi Janne,

> Pencil is an animation/drawing software for Mac OS X, Windows, and
> Linux.

unsure the platforms are relevant in the Debian long description of the
package.

> It lets you create traditional hand-drawn animation (cartoon) using
> both bitmap and vector graphics. Animations can be exported as Flash
> animations.

> Pencil is free and open source.

unsure it's needed in the description of a package belonging to main.

Besides that, I'd be happy to help you with this package if you need (it
looks like it might be your first package), be it for comaintenance or
for sponsorship.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Roberto C . Sánchez]

On Sat, Jul 12, 2008 at 06:01:30PM -0700, Steve Langasek wrote:
> On Sat, Jul 12, 2008 at 06:05:14PM -0400, Roberto C. Sánchez wrote:
> > > I think the first question to resolve is to establish that it *is*
> > > supported...
> 
> > I think that the prudent thing for Debian to do is to continue to
> > support the older kernel if that is the only way to ensure Xen support
> > for the users.  I personally have a few servers running Xen that run
> > stable.  If the support for Xen in a stable release is not suitable, I
> > would have to consider migrating those servers to some other distro.  I
> > would really hate to have to do that.
> 
> The distro used on dom0 is pretty uninteresting, given that part of the
> point of having Xen-style virtualization for servers is to a) be able to run
> different OSes in different guests, and b) not to run services in dom0.[1]
> 
> If the Debian security team is unwilling or unable to provide support for a
> 2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
> Somebody Else's Problem.  I'm certainly happier with that than having us
> /claim/ to support 2.6.18, have users rely on that claim, and then not be
> able to deliver.
> 
While agree that from a technical standpoint, that distro is rather
uninteresting, I don't want to have increase the complexity of the
networks I administer by bringing yet another distro into the mix.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#490702: ITP: pencil -- Traditional animation/drawing software

[Janne Jokitalo]

Package: wnpp
Severity: wishlist
Owner: Janne Jokitalo <[EMAIL PROTECTED]>


* Package name: pencil
  Version : 0.4.4b
  Upstream Author : Pascal Naidon <[EMAIL PROTECTED]> Patrick Corrieri <[EMAIL 
PROTECTED]>
* URL : http://www.les-stooges.org/pascal/pencil/
* License : GPL
  Programming Lang: C++
  Description : Traditional animation/drawing software

Pencil is an animation/drawing software for Mac OS X, Windows, and Linux. It 
lets you create 
traditional hand-drawn animation (cartoon) using both bitmap and vector 
graphics. Animations can be 
exported as Flash animations. Pencil is free and open source.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian release versioning

[Andrei Popescu]

On Sun,13.Jul.08, 11:45:46, Russ Allbery wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> 
> > If I remember correctly, we adopted the rX way of versioning to appease
> > CD-ROM vendors: they did not like us releasing X.Y+1 as a stable update
> > since that meant their X.Y boxes looked out of date, even though the
> > boxes were perfectly fine, and could easily be updated to X.Y+1 via the
> > net.
> >
> > Do we still care about that?
> 
> To me, this argues for continuing to use 5.0r1, 5.0r2, and so forth for
> stable updates and using 5.1 for the -and-a-half release, with 5.1r1,
> 5.1r2, and so forth for additional stable releases based on it.  That
> means we'd probably never use 5.2, but it follows the versioning that
> makes sense for CD-ROM vendors.  The -and-a-half release *does* make their
> CDs potentially out of date since the -and-a-half release may be able to
> install on hardware that the original release can't.
 
That would be true if there was an updated etch installer, which is not 
the case (one has to use the lenny beta 2 installer to install 
etch-and-a-half directly) now. Maybe lenny-and-a-half will also have an 
updated installer?

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: Debian release versioning

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> If I remember correctly, we adopted the rX way of versioning to appease
> CD-ROM vendors: they did not like us releasing X.Y+1 as a stable update
> since that meant their X.Y boxes looked out of date, even though the
> boxes were perfectly fine, and could easily be updated to X.Y+1 via the
> net.
>
> Do we still care about that?

To me, this argues for continuing to use 5.0r1, 5.0r2, and so forth for
stable updates and using 5.1 for the -and-a-half release, with 5.1r1,
5.1r2, and so forth for additional stable releases based on it.  That
means we'd probably never use 5.2, but it follows the versioning that
makes sense for CD-ROM vendors.  The -and-a-half release *does* make their
CDs potentially out of date since the -and-a-half release may be able to
install on hardware that the original release can't.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Die Sensation im Vertrieb - Das ist es, was Sie gesucht haben - Das Produkt des Jahres 2008:

[Vertriebssensation 2008]

Sofern Sie unsere wichtige Email nicht lesen können, senden Sie uns bitte
eine Mail mit der Betreffzeile "Interesse" und Angabe Ihrer vollstaendigen
Kontaktdaten an die Absendermailadresse. Ihre bei uns hinterlegte Email 
lautet: debian-devel@lists.debian.org

Re: [Pkg-xen-devel] Xen status in lenny?

[Steve Langasek]

On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > > The problem I see with that is that people will be left without a
> > > supported dom0 kernel at some point during the etch lifetime. Do we have
> > > a plan to address that? Shouldn't we make it clear that we will support
> > > the etch kernel until a lenny+1/2 kernel is available, for example?

> > Which "we" do you expect will support it?  I haven't heard any comments from
> > the security team indicating that they're willing to provide support for
> > such a stale kernel beyond the normal support lifetime of etch.  If there
> > should happen not to be a lenny+1/2 kernel, how long would the security team
> > be expected to provide security support for 2.6.18?  Until the release of
> > lenny+1?  Until the end of the *lenny* support cycle?

> > > Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> > > for dom0, so it's clear that it is supported?

> > I think the first question to resolve is to establish that it *is*
> > supported...

> If nothing changes, the only choice for users will be to run an etch
> dom0 (or an etch dom0 kernel with a lenny userland, but that doesn't
> change much). An etch dom0 will only be supported until the end of the
> etch support cycle. After that, users will need a supported upgrade
> path (and I would prefer it not to be "use Ubuntu").

I would note that, although built as part of the main 'linux' source package
in Ubuntu, the Xen kernel images are in Ubuntu universe - which means any
Xen-specific code is effectively not guaranteed to be covered by Canonical's
security support anyway.  So you might want to take a closer look at the
security status of this, before deciding that Ubuntu is the right choice for
a security-supported dom0 kernel (or before goading Debian folks into
overcommitting themselves to Xen support in lenny using Ubuntu as a bogeyman
;).

(N.B., I'm not speaking on behalf of the Ubuntu Xen folks; they may indeed
have made arrangements with the security team to provide security coverage
for the Xen kernels - I'm just saying not to assume it's a given.)

> We (Debian) should make a clear statement that users of Debian as dom0
> will have at least one supported configuration at any time during the
> lenny lifetime.

What I don't see you saying is that *you* are volunteering to step up and
help provide security support for this kernel.  So it's "we" when we're
making a statement, but it's still "they" who would have to provide the
actual support, AFAICS.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[Steve Langasek]

On Sat, Jul 12, 2008 at 06:05:14PM -0400, Roberto C. Sánchez wrote:
> > I think the first question to resolve is to establish that it *is*
> > supported...

> I think that the prudent thing for Debian to do is to continue to
> support the older kernel if that is the only way to ensure Xen support
> for the users.  I personally have a few servers running Xen that run
> stable.  If the support for Xen in a stable release is not suitable, I
> would have to consider migrating those servers to some other distro.  I
> would really hate to have to do that.

The distro used on dom0 is pretty uninteresting, given that part of the
point of having Xen-style virtualization for servers is to a) be able to run
different OSes in different guests, and b) not to run services in dom0.[1]

If the Debian security team is unwilling or unable to provide support for a
2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
Somebody Else's Problem.  I'm certainly happier with that than having us
/claim/ to support 2.6.18, have users rely on that claim, and then not be
able to deliver.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]

[1] I can sympathize with users who want to run Xen on systems for
virtualization purposes while also being able to run a full desktop
environment in dom0 where hardware is more accessible; but I think this is
probably a fairly small group of people still given the hardware
requirements, and in any case I don't think that's a use case that should
compel us to overextend ourselves.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Stephen Gran]

This one time, at band camp, Andreas Tille said:
> On Sun, 13 Jul 2008, Raphael Hertzog wrote:
> 
> >What about reading documentation instead of expecting that we feed
> >you everything?
> 
> My intention was to say that IMHO there is an urgent need to explain
> the new trigger feature to our users *before* they stumble by chance
> about stuff they do not understand.

My experience is that the sort of users you seem to be worried about
will not read an explanation ahead of time, docs after the fact, or the
output on their screen.  That being said, if it is really so confusing
that we have to long discussions about what a hypothetical user might
think of this new 'confusing' message, wouldn't it be best to just not
output anything at all?  It's not as though we output status messages
for each maintainer script.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Andreas Tille]

On Sun, 13 Jul 2008, Raphael Hertzog wrote:


What about reading documentation instead of expecting that we feed you
everything?


I'm sorry if I tipped onto several peoples toes: Yes, I know how to
*seek* for the documentation about triggers but wasn't this thread about
"user experience" of Joey Normaluser who upgrades his box (for instance
from Etch to Lenny) and is wondering what these triggers might be?  I do
not think that he has a chance to read what you have suggested me to read
before he is confused about the lot of output.  My intention was to say
that IMHO there is an urgent need to explain the new trigger feature
to our users *before* they stumble by chance about stuff they do not
understand.

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: Java (JAR) desktop integration/admin tool

[George Danchev]

On Sunday 13 July 2008 17:15:01 RalfGesellensetter wrote:
> Dear list,

Hello,

> especially in educational settings, there is an increasing pool of
> platform independent Java applications (JARs) that can be integrated in
> users' desktops.
>
> While Java JDK is freed nowadays, those JAR files are mostly
> closed-source (bluej, javakara, jprologeditor, greenfoot etc.).
>
> Rather than creating wrapping deb-packages with binary content
> ('dirty'), I'd suggest a straight-forward policy plus some desktop
> integration tool for admins:

Hmmm, the debian binary packages are not just a way to blindly move files 
(i.e. the  payload) to the users desktops, it brings some meaningful set of 
well crafted features like relationships between these payloads (depends, 
provides, conflict, etc) thus users are able to manage them is a sane way 
(install, remove, configure, reconfigure,not to mention various a-la `list' 
and `show' queries like dpkg -L, dpkg -S, debsums, and so forth). I'm afraid 
that your proposal has an inherent problem and won't survive or is not 
suitable for broad spread, but probably you can find a way to use it locally 
somehow especially if a robust system accountability and housekeeping is not 
of any interest for you.

-- 
pub 4096R/0E4BD0AB 2003-03-18 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: Java (JAR) desktop integration/admin tool

[Ansgar Burchardt]

Hi,

RalfGesellensetter wrote:
> While Java JDK is freed nowadays, those JAR files are mostly 
> closed-source (bluej, javakara, jprologeditor, greenfoot etc.).
> 
> Rather than creating wrapping deb-packages with binary content 
> ('dirty'), I'd suggest a straight-forward policy plus some desktop 
> integration tool for admins:

> RFC:
> - place all jar files to /usr/share/java or /usr/lib/jar

If I understand your mail right, you want to create an application to
manage the JAR files?  If this is right, the *.jar files should IMO go
to /usr/local/lib/java (or somewhere else in /usr/local).

> - register desktop relevant jar files in /etc/debian-desktop-jar.conf
>   like this:
>   [BlueJ]
>   exec="java -jar /usr/lib/jar/bluej22.jar"
>   menu="BlueJ Java Editor"
>   icon=/usr/share/icons/misc/bluej.png
>   ...

These could then be dropped in /usr/local/share/applications.  This
would also solve the next point (at least for desktops that use the
.desktop files).

> - add some hook that makes those icons show in desktop menus
> - provide some tool that helps registering such JAR apps.

I miss something in this approach:  How would the JAR files be
distributed?  And how can updates be handled?  Having the admin install
them manually on multiple systems is not very comfortable and error
prone.

I think it might be a better idea to make it easy to create Debian
packages out of the JAR files (somewhat similar to dh-make-perl for Perl
packages).  This would make it easy to handle distribution and updates
centrally.  Also it gets the added benefit of dependency handling by
APT.

Regards,
Ansgar

-- 
PGP: 1024D/595FAD19  739E 2D09 0969 BEA9 9797  B055 DDB0 2FF7 595F AD19


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian release versioning

[RalfGesellensetter]

Am Sonntag 13 Juli 2008 schrieb Frans Pop:
> Also, I really dislike the "use .5 for -and-a-half releases" in the
> original proposal. For one thing you cannot exclude the risk that 5
> point releases would be needed for one reason or another before an
> +1/2 release. And it also makes it impossible to distinguish between
> the "regular point update" part of such a release and the "+1/2"
> part.

Agreed. 1/2 could also mean "1 of 2", and .5 name the fifth subversion.
Decimal systems are very modern, while time is still counting in a 
duodecimal manner (12 are a dozen, 60 are a schock: 
http://en.wiktionary.org/wiki/Schock)

The same way, we could call pre-releases "5 [minutes] to Lenny".

Of course, I like the creativeness of leaving the limits of integers 
(Reminding me to Platform 9 3/4 in Harry Potter). After 3.0 and 3.1 - 
has there ever been a PI-Version of Debian BTW? ;)

Just my 2 cent of smalltalk in this thread.
Thanks
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFC: Java (JAR) desktop integration/admin tool

[RalfGesellensetter]

Dear list,

especially in educational settings, there is an increasing pool of 
platform independent Java applications (JARs) that can be integrated in 
users' desktops.

While Java JDK is freed nowadays, those JAR files are mostly 
closed-source (bluej, javakara, jprologeditor, greenfoot etc.).

Rather than creating wrapping deb-packages with binary content 
('dirty'), I'd suggest a straight-forward policy plus some desktop 
integration tool for admins:

RFC:
- place all jar files to /usr/share/java or /usr/lib/jar
- register desktop relevant jar files in /etc/debian-desktop-jar.conf
  like this:
  [BlueJ]
  exec="java -jar /usr/lib/jar/bluej22.jar"
  menu="BlueJ Java Editor"
  icon=/usr/share/icons/misc/bluej.png
  ...
- add some hook that makes those icons show in desktop menus
- provide some tool that helps registering such JAR apps.

Maybe there is already such approach. In some way it would be handy if 
the proposed /etc/debian-desktop-jar.conf could be spreaded easily to 
further desktops. This would imply packaging all files mentioned there 
(jar files, icons) for further deployment.

Especially for Schools running Debian (Edu) such policy/tool could be 
very helpful. 

Please comment on this.
Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFC: Java (JAR) desktop integration/admin tool

[RalfGesellensetter]

Dear list,

especially in educational settings, there is an increasing pool of 
platform independent Java applications (JARs) that can be integrated in 
users' desktops.

While Java JDK is freed nowadays, those JAR files are mostly 
closed-source (bluej, javakara, jprologeditor, greenfoot etc.).

Rather than creating wrapping deb-packages with binary content 
('dirty'), I'd suggest a straight-forward policy plus some desktop 
integration tool for admins:

RFC:
- place all jar files to /usr/share/java or /usr/lib/jar
- register desktop relevant jar files in /etc/debian-desktop-jar.conf
  like this:
  [BlueJ]
  exec="java -jar /usr/lib/jar/bluej22.jar"
  menu="BlueJ Java Editor"
  icon=/usr/share/icons/misc/bluej.png
  ...
- add some hook that makes those icons show in desktop menus
- provide some tool that helps registering such JAR apps.

Maybe there is already such approach. In some way it would be handy if 
the proposed /etc/debian-desktop-jar.conf could be spreaded easily to 
further desktops. This would imply packaging all files mentioned there 
(jar files, icons) for further deployment.

Especially for Schools running Debian (Edu) such policy/tool could be 
very helpful. 

Please comment on this.
Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Raphael Hertzog]

On Sun, 13 Jul 2008, Andreas Tille wrote:
> Sure, that's why I issued this provocation to "trigger" something I
> could listen to.  The only other information about triggers on this list
> was a flamewar which circled basically around formatting of dpkg code
> issues.  Did I missed some announcement which might have helped me
> to understand triggers better?

What about reading documentation instead of expecting that we feed you
everything?

$ dpkg -L dpkg |grep triggers
/usr/share/doc/dpkg/triggers.txt.gz

There's also man dpkg and man deb-triggers. And if some important information
is missing, we accept bugreports and will happily provide the missing bits
of information.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian release versioning

[Ben Finney]

Magnus Holmgren <[EMAIL PROTECTED]> writes:

> On lördagen den 12 juli 2008, martin f krafft wrote:
> > lenny+0.5 would logically be 5.5
> 
> Version strings are *not* floating-point numbers (i.e. e.g. 5.10
> follows 5.9).

Exactly. More specifically, a numbers-with-periods version string
represents a sequence of integers in a hierarchical relationship (e.g.
"major", "minor", "patch", or other meanings), *not* a single number
on a number line.

-- 
 \   “Holy unrefillable prescriptions, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian release versioning

[Magnus Holmgren]

On lördagen den 12 juli 2008, martin f krafft wrote:
> lenny+0.5 would logically be 5.5

Version strings are *not* floating-point numbers (i.e. e.g. 5.10 follows 5.9). 
At least that's the school of thought Debian (dpkg --compare-versions) 
subscribes to with regard to packages.

-- 
Magnus Holmgren[EMAIL PROTECTED]
Debian Developer 


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

Re: Debian release versioning

[Michael Banck]

On Sun, Jul 13, 2008 at 01:51:55AM +0200, Franklin PIAT wrote:
> I can think of five types of releases :
> 
> 1.  Quite incompatible release, like libc5 to libc6 transition.
> 2a. Scheduled release. Which purpose is to update software, fix
> medium bugs, improve hardware support, etc.
> ???(i.e Debian Stable !)
> 2b. Some kind of updates where only End-user ???software-update
> would be updated, but not the core libraries.
> In the proprietary software industry, it can be considered as
> installing a new version of a user application.
> Debian don't have such release (actually we could consider 
> backport to be this kind of thing).
> 3.  Hardware support improvements (e.g Etch-n-a-half)
> 4.  Stability and security improvements (e.g point releases)
> 
> In my perfect world, the major number would be for #1 only. But since
> this rule wasn't followed since woody 3.0 so it's too late and we
> can't
> switch back.

On Sun, Jul 13, 2008 at 07:46:54AM +0200, Frans Pop wrote:
> Paul Wise wrote:
> > I think that the versioning scheme needs to take into account the
> > possible implementation of Joey Hess' CUT (Constantly Usable Testing)
> > idea. I'd suggest 6.X would be CUT releases of lenny+1 and 6.0rY would
> > be stable updates.
> 
> Surely those would be 7.0~ ;-)

Combining the above two comments, I think lenny's release number should
be reassigned to 1:2.6.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490655: ITP: almanah -- almanah is a small application to ease management of a personal diary

[angel]

Package: wnpp
Severity: wishlist
Owner: [EMAIL PROTECTED]


* Package name: almanah
  Version : 0.4.0
  Upstream Author : Philip Withnall <[EMAIL PROTECTED]>
* URL : http://tecnocode.co.uk/projects/almanah/
* License : GPL
  Programming Lang: C
  Description : almanah is a small application to ease management of a 
personal diary

 almanah is a small application to ease management of a personal diary.
 It has basic editing and linking abilities like:
 .
  - adding links to other content to diary entries
  - database encryption
  - search and printing support


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian release versioning

[Frank Lichtenheld]

On Sun, Jul 13, 2008 at 07:46:54AM +0200, Frans Pop wrote:
> Paul Wise wrote:
> > I think that the versioning scheme needs to take into account the
> > possible implementation of Joey Hess' CUT (Constantly Usable Testing)
> > idea. I'd suggest 6.X would be CUT releases of lenny+1 and 6.0rY would
> > be stable updates.
> 
> Surely those would be 7.0~ ;-)

Sure, that will be endless fun to explain to users :)

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Changes detected by lintian on rebuilt packages

[Frank Lichtenheld]

On Sat, Jul 12, 2008 at 08:58:56PM -0500, Raphael Geissert wrote:
> Raphael Geissert wrote:
> > [2] Haven't found any example of these, yet.
> 
> Here's one:
> 
> $ \diff -u xabacus_7.1.7-1_i386.lintian xabacus_7.1.7-1+b1_i386.lintian
> --- xabacus_7.1.7-1_i386.lintian2008-07-12 20:52:30.0 -0500
> +++ xabacus_7.1.7-1+b1_i386.lintian 2008-07-12 20:52:38.0 -0500
> @@ -10,8 +10,6 @@
>  I: xabacus: hyphen-used-as-minus-sign usr/share/man/man6/xabacus.6.gz:41
>  I: xabacus: hyphen-used-as-minus-sign usr/share/man/man6/xabacus.6.gz 6 more 
> occurrences not shown
>  W: xabacus: doc-base-unknown-section xabacus:6 Apps/Math
> -W: xabacus: executable-not-elf-or-script 
> ./usr/share/applications/xabacus.desktop
> -E: xabacus: executable-desktop-file /usr/share/applications/xabacus.desktop 
> 0755
>  I: xabacus: desktop-entry-contains-encoding-key 
> /usr/share/applications/xabacus.desktop:12 Encoding
>  W: xabacus: desktop-entry-invalid-category X 
> /usr/share/applications/xabacus.desktop
>  W: xabacus: menu-item-uses-apps-section /usr/share/menu/xabacus:3

I would think that issues like this don't really warrant binNMUs,
especially if you wind up doing a very large number of them.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

[Andreas Tille]

On Sat, 12 Jul 2008, Colin Watson wrote:


Being completely uneducated is fine - we don't expect everyone to be
dpkg gurus! - but it's worth listening to people who *are* educated
before saying things like "triggers have done more harm than good".


Sure, that's why I issued this provocation to "trigger" something I
could listen to.  The only other information about triggers on this list
was a flamewar which circled basically around formatting of dpkg code
issues.  Did I missed some announcement which might have helped me
to understand triggers better?

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490627: ITP: igstk -- development platform for image-guided surgery applications

[Dominique Belhachemi]

Package: wnpp
Severity: wishlist
Owner: Dominique Belhachemi <[EMAIL PROTECTED]>


* Package name: igstk
  Version : 3.0.0
  Upstream Author : IGSTK-Developer <[EMAIL PROTECTED]>
* URL : http://www.igstk.org/
* License : BSD
  Programming Lang: C++
  Description : development platform for image-guided surgery applications

The Image-Guided Surgery Toolkit (IGstk: pronounced IGStick) is a high-level 
component-based 
framework providing common functionality for image-guided surgery applications.
This software framework consists of a set of high-level components integrated 
with other 
low-level open source software libraries and application programming interfaces 
(API) from 
hardware vendors.
The cornerstone of IGstk is robustness. IGstk provides the following high-level 
functionality: 
Ability to read and display medical images including CT and MRI in DICOM format.
An interface to common tracking hardware. A graphical user interface and 
visualization
capability including a four-quadrant view (axial, sagittal, coronal, and 3D) as 
well
as a multi-slice axial view (from 1 by 1 to many by many such as 10 by 10).
Registration: point based registration and a means for selecting these points. 
Robust common 
internal software services for logging, exception-handling and problem 
resolution.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Package management unsafe?

[Franklin PIAT]

On Sun, 2008-07-13 at 16:19 +0930, Karl Goetz wrote:
> On Sun, 2008-07-13 at 02:13 +0200, Franklin PIAT wrote:
> > Hello,
> > 
> > On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote:
> > > Andrei Popescu  gmail.com> writes:
> > > 
> 
> > 
> > One costly solution would be to get the client the send a challenge to a
> > trusted server, which would respond by gpg-signed the challenge + the
> > checksum of current .Release file.
> 
> How would all these schemes work with offline mirrors? eg, ones that are
> built, and used without an internet connection for a month.

You would be warned that your security update server can't be
contacted/validated, which is accurate.

BTW, of course, the GPG wouldn't have to be Debian key, but any trusted
key for that purpose (e.g including corporate, Debian derivative key).

Franklin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]