Re: bash version inconsistency in sarge

[Matthias Klose]

Florian Weimer writes:
> Something strange has happened to the bash version in sarge:
> 
> version inconsistency between source and binary package:
>   source package: bash, version: 2.05b-2-26
>   binary package: bash, version: 2.05b-26
> 
> If I read policy correctly, the upstream version is "2.05b-2".
> Something (debhelper?) drops the "-2" during the build process.  Is
> this intentional?  Does anybody know what's going on?

yes, repackaged source some years ago. the -2 is dropped from the
binary version.


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

Re: apt with index diff support

[Andreas Metzler]

Daniel Burrows <[EMAIL PROTECTED]> wrote:
> On Saturday 10 September 2005 07:46 am, Andreas Metzler wrote:
>> Having to specify this at the commandline is messy, is there a way to put
>> this in /etc/apt.conf.d/? I've tried in vain using

>> APT::URL-Remap::http://merkel.debian.org/~aba/debian/
>> {"http://ftp.at.debian.org/debian";};

> I would expect that removing the braces would do the right thing.

> APT::URL-Remap::http://merkel.debian.org/~aba/debian/ 
> "http://ftp.at.debian.org/debian";;

Thanks,
it does not help though; I still get:
(SID)[EMAIL PROTECTED]:/# apt-cache show apt
E: Syntax error /etc/apt/apt.conf.d/80incremental:2: Extra junk at end of file
cu andreas
PS: I got tht lots-of-curly-braces-idea from
/etc/apt/apt.conf.d/70debconf.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


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

Re: Bug#327081: ITP: rpmstrap -- bootstrap a basic RPM-based system

[Anthony Towns]

On Wed, Sep 07, 2005 at 02:08:04PM +0200, Piotr Roszatycki wrote:
> * Package name: rpmstrap
>   Version : 0.5
> * URL : http://hackers.progeny.com/~sam/rpmstrap/
> * License : GPL
>   Description : bootstrap a basic RPM-based system
> 
>  rpmstrap is a tool for bootstrapping a basic RPM-based system. It is inspired
>  by debootstrap, and allows you to build chroots and basic systems from RPM
>  sources.

Looking at the source it seems more "based on" than "inspired by",
particular to "rpmstrap" itself, though the "functions" and "scripts/*"
files sure seem more derivative than just coincidently similar. If
so, it's in violation of debootstrap's license (by not including
debootstrap's copyright text), and it seems fairly rude to relicense it
from debootstrap's BSD-ish license to GPLv2+, not to mention expunging
my name and copyright notice from the source, and for that matter all
references to debootstrap.

Removing the copyright's a license violation, and presumably renders the
program undistributable and unpackagable, afaics.

At least Bastian Blank's cdebootstrap was written from scratch to justify
its different license and lack of recognition. Colour me unimpressed.

Cheers,
aj



signature.asc
Description: Digital signature

Handling event device files [was: Bug#324604: [Fwd: The bug persists]]

[Frank Lichtenheld]

Hi.

I've a problem here where I'm unsure how to handle it. A mail from
the corresponding bug report is appended for reference but I will
try to explain it in my own words:

pbbuttonsd is a program for Apple Powerbooks that handles things like
powermanagment and special keys. It uses the event device files
(/dev/input/event*) to monitor attached input devices. The problem
now is that makedev only generates four of these event device files
(event0 to event3). On my fully standard Powerbook with an attached
USB mouse I have already _six_ of these those, if I would plug in
e.g. an external keybord or a second pointer device I could easily
have seven or eight of them. This leads to problems for users that
have a static /dev/ (i.e. don't use udev) since pbbuttonsd will
not see events from some of the devices.

There are three possible solutions to this AFAICS:

1) generate more device files in the postinst of the package with
   mknod (which is a policy violation IIRC)
2) make makedev produce more of these files (but probably most users
   don't need them, at least not on desktop PCs which have seldomly
   two mouses or keyboards)
3) Just tell each user to fix it himself (e.g. in a README.Debian
   file). Not really complicated, just some calls to mknod
   (or an installation of udev), but...

Any hints or comments would be welcome.

Gruesse,
Frank Lichtenheld

- Forwarded message from Matthias Grimm <[EMAIL PROTECTED]> -

Subject: Bug#324604: [Fwd: The bug persists]
Reply-To: Matthias Grimm <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
X-Debian-PR-Message: report 324604
X-Debian-PR-Package: pbbuttonsd
X-Debian-PR-Keywords: unreproducible
From: Matthias Grimm <[EMAIL PROTECTED]>
To: Frank Lichtenheld <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]

On Tue, 6 Sep 2005 15:39:22 +0200
Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 06, 2005 at 02:12:28PM +0200, Matthias Grimm wrote:
> > On Tue, 06 Sep 2005 12:41:08 +0200
> > Eugen Dedu <[EMAIL PROTECTED]> wrote:
> > 
> > > [4] ids - 3 45e 47 300  Name: Microsoft Microsoft 5-Button Mouse with 
> > > IntelliEye(TM)
> > >Supported Events:
> > >0 (Reset) 1 (Key) 2 (Relative)
> > 
> > Here it is :-) Only an event device file was missed. Debian has no
> > device handler installed by default and I think this was the cause of
> > our trouble. 
> 
> Just for the record, which file?
> But that certainly explain why I couldn't reproduce that since I
> run udev here.

/dev/input/event4 was missing. A "mknod /dev/input/event4 c 13 68"
solved the problem.

 Best Regards
   Matthias

- End forwarded message -

-- 
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: Handling event device files [was: Bug#324604: [Fwd: The bug persists]]

[Marco d'Itri]

On Sep 11, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

> 1) generate more device files in the postinst of the package with
>mknod (which is a policy violation IIRC)
Right.

> 2) make makedev produce more of these files (but probably most users
>don't need them, at least not on desktop PCs which have seldomly
>two mouses or keyboards)
It could be done, but many users would need anyway to adjust the
permissions (which is hard, because a device can easily move among
nodes).

> 3) Just tell each user to fix it himself (e.g. in a README.Debian
>file). Not really complicated, just some calls to mknod
>(or an installation of udev), but...
I favour this. If for some weird reason an user does not want to use
udev, let him deal with the results without having to make your package
more complex.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Handling event device files [was: Bug#324604: [Fwd: The bug persists]]

[Christoph Hellwig]

On Sun, Sep 11, 2005 at 01:05:36PM +0200, Frank Lichtenheld wrote:
> 2) make makedev produce more of these files (but probably most users
>don't need them, at least not on desktop PCs which have seldomly
>two mouses or keyboards)

That's the right choice.  Lot's of laptops have additional even sources,
as do various external disk enclosures or random usb devices.  In
addition the uinput driver can create additional sources from userspace
input.  makedev should create all 32 specified /dev/input/eventN
devices.


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

Re: apt with index diff support

[Michal Politowski]

On Sun, 11 Sep 2005 09:18:57 +0200, Andreas Metzler wrote:
> Daniel Burrows <[EMAIL PROTECTED]> wrote:
> > On Saturday 10 September 2005 07:46 am, Andreas Metzler wrote:
> >> Having to specify this at the commandline is messy, is there a way to put
> >> this in /etc/apt.conf.d/? I've tried in vain using
> 
> >> APT::URL-Remap::http://merkel.debian.org/~aba/debian/
> >> {"http://ftp.at.debian.org/debian";};
> 
> > I would expect that removing the braces would do the right thing.
> 
> > APT::URL-Remap::http://merkel.debian.org/~aba/debian/ 
> > "http://ftp.at.debian.org/debian";;
> 
> Thanks,
> it does not help though; I still get:
> (SID)[EMAIL PROTECTED]:/# apt-cache show apt
> E: Syntax error /etc/apt/apt.conf.d/80incremental:2: Extra junk at end of file

APT { URL-Remap::http://merkel.debian.org/~aba/debian/ 
"http://ftp.at.debian.org/debian";; };
at least parses (should the method of scoping make any difference, or is it a 
bug?),
but seems not to have any effect.

> PS: I got tht lots-of-curly-braces-idea from
> /etc/apt/apt.conf.d/70debconf.

DPkg::Pre-Install-Pkgs wants a list, this is the reason for braces, I think.

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.


signature.asc
Description: Digital signature

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Henrique de Moraes Holschuh]

On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
> > A GPL package (which only depends on libcurl3-gnutls) is installed:
> > libcurl3-gnutls gets pulled in
> >
> > A package that can't work with gnuTLS version of libcurl (and
> > therefore libcurl3-gnutls conflicts with it) is installed:
> > libcurl3 gets pulled in
> >
> > Packages of both above types are installed:
> > Unresolvable. However, this is also not possible now, unless
> > a GPL package is linking against the OpenSSL-using libcurl,
> > and therefore the GPL package has an RC bug.
> 
> It could certainly be resolved: different libraries should install
> different files.

You also need different SYMBOLS. Which requires symbol versioning, and that
the symbols provided bu curl+gnutls be differently versioned than the
symbols provided by curl+openss.

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: curl situation is intolerable

[Henrique de Moraes Holschuh]

On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> It is *absolutely intolerable* to declare such conflicts for shared
> libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
> HAVE DIFFERENT NAMES.

The package has to build libraries with differently versioned symbols as
well, to avoid total app meltdown if both libraries are loaded into the same
address space.

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

insighttoolkit2 is now available

[bear]

hi debian developers,

  I finished packaging my insighttoolkit2 (www.itk.org) and uploaded it to
mentors.debian.net. Three packages are available:
libinsighttoolkit2-dev, libinsighttoolkit2, insighttoolkit2-examples
  
  Please check if they are ok. I wonder if anyone can help to sponsor it. 
Thanks!

Regards,
-Guanglei



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

xshogi: menu question and arm build problem

[Craig P. Steffen]

I'm interested in becoming a Debian developer.  I'd like to work on
gnushogi as an initial package, and I have set an ITA on it.  Gnushogi
doesn't have any bugs filed against it, but I have the following
questions:

Gnushogi generates the binary package xshogi, a simulation of Shogi,
a Japanese game similar to european chess.  The traditional pieces
are marked with Kanji, Japanese language ideograms.  The program has
an option to use a slightly more western style symbols.  The menu
entry currently set up for Xshogi runs the program with Japanese
symbols.  I think it would be nice to have two menu options, one to
invoke the program as now labelled "Xshogi (Kanji)" and another menu
item "xshogi (western)" with the non-Kanji symbols.  Is this a
reasonable thing to do?  

Secondly, there's no bug filed, but the package tracking system pages
lists that the package hasn't gone into testing because it seems that
there's a build error on "arm" architecture.  One of the files
generates the following error:

pattern.c:506: fatal error: internal consistency failure

First of all, does this mean that the package isn't being pushed out
on _any_ architecture because of this one failure?  If that's true, in
the absense of any ability to reproduce this error, is it a reasonable
short-term work-around to disable building the package for arm until
the error can be weeded out?  

Thanks for any advice.  Sincerely,

Craig Steffen

-- 
[EMAIL PROTECTED]
public key available at http://www.craigsteffen.net/GPG/
current goal: use a CueCat scanner to inventory my books
career goal: be the first Vorlon Time Lord


signature.asc
Description: Digital signature

Re: Bug#318590: curl situation is intolerable

[Domenico Andreoli]

On Sun, Sep 11, 2005 at 10:54:17AM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> > It is *absolutely intolerable* to declare such conflicts for shared
> > libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
> > HAVE DIFFERENT NAMES.
> 
> The package has to build libraries with differently versioned symbols as
> well, to avoid total app meltdown if both libraries are loaded into the same
> address space.

hmm.. i didn't realized this. how does it work?

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

Re: xshogi: menu question and arm build problem

[Christoph Berg]

Re: Craig P. Steffen in <[EMAIL PROTECTED]>
> Gnushogi generates the binary package xshogi, a simulation of Shogi,
> a Japanese game similar to european chess.  The traditional pieces
> are marked with Kanji, Japanese language ideograms.  The program has
> an option to use a slightly more western style symbols.  The menu
> entry currently set up for Xshogi runs the program with Japanese
> symbols.  I think it would be nice to have two menu options, one to
> invoke the program as now labelled "Xshogi (Kanji)" and another menu
> item "xshogi (western)" with the non-Kanji symbols.  Is this a
> reasonable thing to do?  

Can the setting changed from within the program or from a config file?
If not, does it make sense to provide both alternatives? If yes, just
provide two menu entries.

> Secondly, there's no bug filed, but the package tracking system pages
> lists that the package hasn't gone into testing because it seems that
> there's a build error on "arm" architecture.  One of the files
> generates the following error:
> 
> pattern.c:506: fatal error: internal consistency failure

This sounds like an internal compiler error. The build log isn't that
old yet, I'd wait for the buildd maintainer to review it, he will
probably re-schedule gnushogi for rebuild. Otherwise, the package will
get an FTBFS bug filed.

> First of all, does this mean that the package isn't being pushed out
> on _any_ architecture because of this one failure?  If that's true, in
> the absense of any ability to reproduce this error, is it a reasonable
> short-term work-around to disable building the package for arm until
> the error can be weeded out?  

Yes, it means that the package won't go into testing at all. No, there
is no way to circumvent that except for getting it to build on arm.
Either wait (preferably), or find someone that builds it on arm for
you.

Christoph

PS: debian-mentors might have been more approriate.
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#327687: ITP: gnome-icon-theme-dropline-neu -- A smooth, shiny and kind of 'fun looking' theme for GNOME

[Tiago Bortoletto Vaz]

Package: wnpp
Severity: wishlist
Owner: Tiago Bortoletto Vaz <[EMAIL PROTECTED]>


* Package name: gnome-icon-theme-dropline-neu
  Version : 0.3
  Upstream Author : Silvestre Herrera <[EMAIL PROTECTED]>
* URL : http://art.gnome.org/themes/icon/1100
* License : GPL
  Description : A smooth, shiny and kind of 'fun looking' theme for GNOME

A smooth, shiny and saturated-color Scalable Vector Graphic (SVG)
iconset for GNOME Desktop.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-ibook-g4
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)


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

Welcome to info tourisme

[info tourisme]

The subscription of the email address: 

debian-devel@lists.debian.org

To the mailing list: 

info tourisme

is all set. Thanks for subscribing! 

Date of this subscription: Sun Sep 11 11:18:23 2005

Please save this email message for future reference. 

---

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]

- 


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

info tourisme Mailing List Confirmation

[info tourisme]

This message has been sent to you as the final step to confirm your
email *removal* for the following list: 

info tourisme

To confirm this unsubscription, please follow the below URL:



(Click the URL above or, copy and paste the URL into your browser)

Doing so will *remove* you to this list. 

---

The following is the description given for this list: 

[EMAIL PROTECTED]

---

This double opt-out confirmation email was sent to protect the privacy
of the owner of this email address. 

Furthermore, the following privacy policy is associated with this list: 

[EMAIL PROTECTED]

Please read and understand this privacy policy. 

If you did not asked to be removed from this particular list, please
do not visit the confirmation URL above. The confirmation for 
removal will not go through and no other action on your part 
will be needed.

To contact the owner of this email list, please use the below address: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]


- 


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

Re: Bug#318590: curl situation is intolerable

[Henrique de Moraes Holschuh]

On Sun, 11 Sep 2005, Domenico Andreoli wrote:
> On Sun, Sep 11, 2005 at 10:54:17AM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> > > It is *absolutely intolerable* to declare such conflicts for shared
> > > libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
> > > HAVE DIFFERENT NAMES.
> > 
> > The package has to build libraries with differently versioned symbols as
> > well, to avoid total app meltdown if both libraries are loaded into the same
> > address space.
> 
> hmm.. i didn't realized this. how does it work?

Version the symbols of one of the libs like this:
  CURLGTLS_ABI
and the other lib like this:
  CURLOSSL_ABI

  where ABI is the ABI version, such as 20, 30...

Of course, you also need the files to be named differently so that the libs
can coexist.

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

info tourisme Unsubscription

[info tourisme]

The removal of the email address:

debian-devel@lists.debian.org

>From the mailing list: 

info tourisme 

is all set.

Date of this removal: Sun Sep 11 11:53:01 2005

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 

[EMAIL PROTECTED]

- 



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

Re: insighttoolkit2 is now available

[Andreas Tille]

On Sun, 11 Sep 2005, bear wrote:


 I finished packaging my insighttoolkit2 (www.itk.org) and uploaded it to
mentors.debian.net. Three packages are available:
libinsighttoolkit2-dev, libinsighttoolkit2, insighttoolkit2-examples

As I said this package is relevant for Debian-Med and if noone else would
take over this sponsoring job I would take over this job.  Because I
have a lot of packages I started to loose overview about the packages.
That's why I would prefer if you would include

  Uploaders: Andreas Tille <[EMAIL PROTECTED]>

into the control fields.  I will not upload the package without asking
you but this automatically brings up bugs against this package above
my horizont.


 Please check if they are ok.

Not really:

mkdir -p Build
cp debian/CMakeCache.txt.debian Build/CMakeCache.txt
cd Build; cmake ..
CMake Error: The current CMakeCache.txt directory 
/home/andreas/debian-maintain/sponsor/itk/insight/insighttoolkit2-2.2.0/Build/CMakeCache.txt
 is different than the directory 
/home/bear/insightdeb/insighttoolkit2-2.2.0/Build where CMackeCache.txt was 
created. This may result in binaries being created in the wrong place. If you 
are not sure, reedit the CMakeCache.txt
CMake Error: The source 
"/home/andreas/debian-maintain/sponsor/itk/insight/insighttoolkit2-2.2.0/CMakeLists.txt" 
does not match the source "/home/bear/insightdeb/insighttoolkit2-2.2.0/CMakeLists.txt" 
used to generate cache.  Re-run cmake with a different source directory.

I do not know cmake at all, but it seems to depend from a fixed path which
leads to a FTBFS bug.

Kind regards and thanks for caring for this package

  Andreas.

--
http://fam-tille.de


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

Re: apt with index diff support

[Michael Vogt]

Hi Andreas,

thanks for your feedback.

On Sat, Sep 10, 2005 at 04:46:09PM +0200, Andreas Metzler wrote:
> Michael Vogt <[EMAIL PROTECTED]> wrote:
> [...]
> > 2. merkel does not have the actual package files
[..]
> Having to specify this at the commandline is messy, is there a way to put
> this in /etc/apt.conf.d/? I've tried in vain using
> 
> APT::URL-Remap::http://merkel.debian.org/~aba/debian/ 
> {"http://ftp.at.debian.org/debian";};

Please add (in e.g. /etc/apt/apt.conf.d/50remap):
APT::URL-Remap::"http://merkel.debian.org/~aba/debian/"; 
"http://ftp.de.debian.org/debian/";; 

Note the quotes around the uri, if they are omitted apt will consider
the // as the start of a comment. 

Cheers,
 Michael

-- 
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo


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

Re: Bug#326779: fixed in wmfire 1.2.1-6

[Charles Fry]

>   In the future, please try to find out if your package is part of some
>   transition, in order not to interfere with it. The Release Team is
>   also aware this information is not very easily accessible, and will
>   think of ways of improving the situation.

First of all, I apologize for complicating this matter with my upload. I
will be more careful to check for this before uploading newly adopted
packages.

I am sure that this idea has been discussed before, but it seems to me
that it would be fairly straightforward to implement a mechanism whereby
all packages involved in transitions could be explicitely marked as
frozen in unstable, preventing new uploads from succeeding before the
transition was complete.

I absolutely agree that a certain amount of diligence should be required
from all developers, but it also seems that technical solutions should
also be put in place insasmuch as possible. (Maybe I simply
under-estimate the difficulty of this proposition, being entirely
unfamiliar with the current infrastructure.)

cheers,
Charles

-- 
Here's something
That could
Even soak
The whiskers off
A radio joke
Burma-Shave
http://burma-shave.org/jingles/1938/heres_something


signature.asc
Description: Digital signature

Re: Handling event device files [was: Bug#324604: [Fwd: The bug persists]]

[Peter 'p2' De Schrijver]

> 2) make makedev produce more of these files (but probably most users
>don't need them, at least not on desktop PCs which have seldomly
>two mouses or keyboards)

That's probably the right solution. Device nodes hardly take any
resources anyway.

Cheers,

Peter (p2).


signature.asc
Description: Digital signature

Re: better init.d/* : who carres ?

[Anthony DeRobertis]

Henrique de Moraes Holschuh wrote:

> No.  They are not even "supposed" to be scripts at all, it is pretty ok to
> use binary initscripts (but most people don't, and it really helps for stuff
> like that to be easy to debug, and binary is anything but).

Ummm, not it's not.

In particular, you'd be violating policy by

1) Placing binaries in /etc, in violation of FHS 3.4.

2) Policy 9.3.x, which says they're scripts multiple times

3) I strongly suspect you'd be violating Policy 10.7.3 on the behavior
   of configuration files.


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

Re: better init.d/* : who carres ?

[Petter Reinholdtsen]

[Henrique de Moraes Holschuh]
> No.  They are not even "supposed" to be scripts at all, it is pretty ok to
> use binary initscripts

[Anthony DeRobertis]
> Ummm, not it's not.

And to make sure the scripts start in the correct order, the init.d
scripts should include dependency information, for example in the LSB
standard comment format described in http://wiki.debian.net/?LSBInitScripts>.  If all init.d scripts used
this format, it is simple to reorder the boot sequence according to
this info, and to start scripts in parallel to speed up the boot
process.


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

nonpublic shared libraries (repost; was: Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self)

[Justin Pryzby]

This was originally sent to -mentors, but elicited no response, so I'm
reposting here:

I actually had postponed a message about all these questions for some
6+ months now, while I tried to phrase the questions in a more useful
way.  This thread caused me to regain interest.  Hopefully someone
here can provide insight, otherwise I guess I will try on -devel.

On Tue, Sep 06, 2005 at 07:18:17PM +0200, Frank K?ster wrote:
> Justin Pryzby <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote:
> >> Justin Pryzby <[EMAIL PROTECTED]> wrote:
> >> 
> >> > Could someone else also comment on how applications should deal with
> >> > shared libraries which are not intended to be used by other programs?
> >> 
> >> If they aren't used by other programs, there's no need to produce a
> >> library.  Perhaps it's convienient to create static libraries during
> >> compilation and link against these, but shared libraries are of no use. 
> > What if there are many binaries (10s of them) in your package, and you
> > want to use shared libs purely for resource efficiency (disk and
> > memory)?
> 
> You're right, that's an other reason for a shared library.
In which case, should the shared libraries go into a separate package?

What should they be named (filenames and sonames)?  Should they be in
/usr/lib/ or in /usr/lib/pkg/?  If /u/l/pkg/, what is the recommended
way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)?

Is it still okay if the binary interface is not at all stable, or
guaranteed to be compatible between versions?  I'm thinking of the
case where a Debian packager adds shared lib support for better
resource efficiency, but upstream doesn't implement it, and interfaces
change at potentially every new release.  Is it sufficient (if the
libs are in a separate package) to have the libs and the binaries both
Depends: pkg-{libs,bin} (=${Source-Version})?

It seem to me that there is no reason to requires libs to be in a
separate package, though it might be convenient to make this division,
but probably no deeper reason, correct?  For a multiple-binary
package, it could be used as one of the arch-dep packages, if the
indep packages are significanly large to warrent the split.

Thanks,
Justin


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

Stop Spam

[HeatherLHam]

How can i stop all this spam? I have tried to search around and i am out of 
solutions.  Please help me,
Thanks, Heather

Re: nonpublic shared libraries (repost; was: Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self)

[Peter Samuelson]

[Justin Pryzby]
> In which case, should the shared libraries go into a separate package?

I wouldn't bother unless there are multiple binary packages already
which will require the library, and they don't already depend on each
other.  And this is probably a fairly rare case.

Basically, if there's no reason for anyone to install the library
package but *not* the binary package that requires it, then there's no
reason the library package should be separate.

> What should they be named (filenames and sonames)?  Should they be in
> /usr/lib/ or in /usr/lib/pkg/?  If /u/l/pkg/, what is the recommended
> way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)?

/usr/lib/pkg/, and I would use rpath.  Why not?  The problems with
rpath do not apply to the case where libraries and binaries are tightly
coupled, like they're built from the same source and are in the same
binary package.

> Is it still okay if the binary interface is not at all stable, or
> guaranteed to be compatible between versions?

I think it's fine - especially if you don't have a separate library
package, but even if you do - just so long as you have a (=
${Source-Version}) in your Depends lines, as you said.

> It seem to me that there is no reason to requires libs to be in a
> separate package, though it might be convenient to make this
> division, but probably no deeper reason, correct?

I agree, but maybe someone else can think of deeper reasons.

Note that you wouldn't separate foo-lib just for arch-dependent
vs. arch-independent reasons anyway - at least if we're talking about
ELF libraries here.  Because arch-independent packages can't make use
of ELF libraries directly anyway.

Peter


signature.asc
Description: Digital signature

Re: nonpublic shared libraries (repost; was: Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self)

[Marco d'Itri]

On Sep 12, Justin Pryzby <[EMAIL PROTECTED]> wrote:

> This was originally sent to -mentors, but elicited no response, so I'm
> reposting here:
I agree with the answer by Peter Samuelson.
Most of the policy requirements about libraries are only relevant if
they are shared among non-cooperating packages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: curl situation is intolerable

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

> On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
>> It is *absolutely intolerable* to declare such conflicts for shared
>> libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
>> HAVE DIFFERENT NAMES.
>
> The package has to build libraries with differently versioned symbols as
> well, to avoid total app meltdown if both libraries are loaded into the same
> address space.

Yes, but I don't mind that nearly as much.  That's a much rarer
obstacle than one which simply segregates Debian packages into two
separate camps, and every use must pick one or the other.  That's what
the current "solution" amounts to.


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

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Thomas Bushnell BSG]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

>> It could certainly be resolved: different libraries should install
>> different files.
>
> You also need different SYMBOLS. Which requires symbol versioning, and that
> the symbols provided bu curl+gnutls be differently versioned than the
> symbols provided by curl+openss.

This would be nice too, but Debian does not have a rule that different
libraries must never provide the same symbol names. 


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

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Olaf van der Spek]

On 9/12/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> 
> >> It could certainly be resolved: different libraries should install
> >> different files.
> >
> > You also need different SYMBOLS. Which requires symbol versioning, and that
> > the symbols provided bu curl+gnutls be differently versioned than the
> > symbols provided by curl+openss.
> 
> This would be nice too, but Debian does not have a rule that different
> libraries must never provide the same symbol names.

But doesn't it make much more sense to ensure no two libraries provide
the same symbol?

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Thomas Bushnell BSG]

Olaf van der Spek <[EMAIL PROTECTED]> writes:

> On 9/12/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>> 
>> >> It could certainly be resolved: different libraries should install
>> >> different files.
>> >
>> > You also need different SYMBOLS. Which requires symbol versioning, and that
>> > the symbols provided bu curl+gnutls be differently versioned than the
>> > symbols provided by curl+openss.
>> 
>> This would be nice too, but Debian does not have a rule that different
>> libraries must never provide the same symbol names.
>
> But doesn't it make much more sense to ensure no two libraries provide
> the same symbol?

If they have compatible APIs.

So: if they are compatible, then yes, they should cover the same
namespace, and then each should Provide the same package name.

Or, if they are not, they should provide different symbol names.

Or, as a second-best, they could be in different file names, with
colliding symbol name spaces.

Or, as the absolutely worst, they could be the same file name and the
packages could conflict.

Unfortunately, the last "solution" has been chosen.


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

Re: insighttoolkit2 is now available

[bear]

Hi Andreas,

Thanks for your sponsor. I have added the "Uploads:" line in the control file
and fixed the bug in CMakeCache.txt.debian. The new packages are uploaded to
mentors.debian.net, namely

libinsighttoolkit2_2.2.0-2_i386.deb
libinsighttoolkit2-dev_2.2.0-2_all.deb
insighttoolkit2-examples_2.2.0-2_all.deb

Please recheck if it is OK. Thanks!

Best regards,
Guanglei


In your mail:
>From: Andreas Tille <[EMAIL PROTECTED]>
>Reply-To: 
>To: bear <[EMAIL PROTECTED]>
>Subject: Re: insighttoolkit2 is now available
>Date:Sun, 11 Sep 2005 21:52:32 +0200 (CEST)
>
>On Sun, 11 Sep 2005, bear wrote:
> 
> >  I finished packaging my insighttoolkit2 (www.itk.org) and uploaded it to
> > mentors.debian.net. Three packages are available:
> > libinsighttoolkit2-dev, libinsighttoolkit2, insighttoolkit2-examples
> As I said this package is relevant for Debian-Med and if noone else would
> take over this sponsoring job I would take over this job.  Because I
> have a lot of packages I started to loose overview about the packages.
> That's why I would prefer if you would include
> 
>Uploaders: Andreas Tille <[EMAIL PROTECTED]>
> 
> into the control fields.  I will not upload the package without asking
> you but this automatically brings up bugs against this package above
> my horizont.
> 
> >  Please check if they are ok.
> Not really:
> 
> mkdir -p Build
> cp debian/CMakeCache.txt.debian Build/CMakeCache.txt
> cd Build; cmake ..
> CMake Error: The current CMakeCache.txt directory
/home/andreas/debian-maintain/sponsor/itk/insight/insighttoolkit2-2.2.0/Build/CMak
eCache.txt is different than the directory
/home/bear/insightdeb/insighttoolkit2-2.2.0/Build where CMackeCache.txt was
created. This may result in binaries being created in the wrong place. If you 
are
not sure, reedit the CMakeCache.txt
> CMake Error: The source
"/home/andreas/debian-maintain/sponsor/itk/insight/insighttoolkit2-2.2.0/CMakeList
s.txt" does not match the source
"/home/bear/insightdeb/insighttoolkit2-2.2.0/CMakeLists.txt" used to generate
cache.  Re-run cmake with a different source directory.
> 
> I do not know cmake at all, but it seems to depend from a fixed path which
> leads to a FTBFS bug.
> 
> Kind regards and thanks for caring for this package
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
>



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

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

[Henrique de Moraes Holschuh]

On Sun, 11 Sep 2005, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> >> It could certainly be resolved: different libraries should install
> >> different files.
> >
> > You also need different SYMBOLS. Which requires symbol versioning, and that
> > the symbols provided bu curl+gnutls be differently versioned than the
> > symbols provided by curl+openss.
> 
> This would be nice too, but Debian does not have a rule that different
> libraries must never provide the same symbol names. 

Of course we don't.  It is a bug if you try to link to two libs that cause a
symbol clash.  OTOH, if you don't ever try to link them, why would we forbid
it?

So, find another excuse. Maybe there is a better way of fixing the bug (my
favourite would be to fully version openssl and gnutls, and get libcurl to
not change ABIs at all when linked to either.  You'd only need to link
libcurl to gnutls, then.  No more license headaches).

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

NFL LOCK OF THE MONTH MONDAY NIGHT!

[chewlocka]

Title: E-mail message content





















What a 1st week we had with our NFL plays here at Lock and Win! Well just cause the weekend is over doesn't mean our winning is! The Eagles and Falcons are all set to replay last years NFC Championship Game and we have the WINNER for you! We are so sure about this game we are putting up DOUBLE what we usually do on a premium play and you should as well! Will McNabb and Owens explode or implode? Will Vick take the next step to greatness? We know the answers and we got the winner for you! Do yourself a favor and get in on this game! This is the one you don't wanna miss! DO NOT MISS OUT! BUY IT NOW THANK US LATER!
 
 
 
www.lockandwin.com
 
 
DISCLAIMER:
This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message immediately.































--- Sent by UNREGISTERED VERSION of Atomic Mail Sender.Please register to remove this message.

Re: curl situation is intolerable

[Paul TBBle Hampson]

On Sun, Sep 11, 2005 at 08:59:11PM -0700, Thomas Bushnell BSG wrote:
> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:

>> On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
>>> It is *absolutely intolerable* to declare such conflicts for shared
>>> libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
>>> HAVE DIFFERENT NAMES.

>> The package has to build libraries with differently versioned symbols as
>> well, to avoid total app meltdown if both libraries are loaded into the same
>> address space.

> Yes, but I don't mind that nearly as much.  That's a much rarer
> obstacle than one which simply segregates Debian packages into two
> separate camps, and every use must pick one or the other.  That's what
> the current "solution" amounts to.

Mind you, the license/OpenSSLCallback conflict neccessarily segregates the
packages into two camps, those which are GPL, and those which need the callback
only supplied by the OpenSSL-linked libcurl.

The difficulty lies in handling those which aren't in either group so they can
link to whatever libcurl3 is present, without fear or favour.

The secondary difficulty is making sure that no Sarge packages which use the
callback find themselves broken by a partial upgrade (although a conflicts
could be used to force both parts to migrate if neccessary)

The first mitigating factor is that both present the same API to the program,
and the same ABI to the linker. (The missing callback just returns -EFAIL if
you try to set it on a non-OpenSSL version of libcurl) so it's very possible to
link things that can load either library. I like the suggestion for versioning
the symbols of libcurl depending on what that lib's linked to.

The second mitigating factor is that I couldn't find any code in Debian sid or
experimental that sets this callback. I didn't check Sarge, though. So once the
gnuTLS support in libcurl is sufficiently featureful to meet it's promised API,
it may be able to be just slipped in underneath with no one the wiser, assuming
gnuTLS has versioned symbols, which I believe it has.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgp0cWJ8rBR7o.pgp
Description: PGP signature

Re: curl situation is intolerable

[Thomas Bushnell BSG]

Paul TBBle Hampson <[EMAIL PROTECTED]> writes:

> Mind you, the license/OpenSSLCallback conflict neccessarily
> segregates the packages into two camps, those which are GPL, and
> those which need the callback only supplied by the OpenSSL-linked
> libcurl.

You misunderstand my complaint.

I do not care that a given package cannot link to SSL and also be
GPLd.  That's a hassle, but it's endurable.

What I complain is that, once the packages have been so segregated, it
is now *impossible* to even install both kinds on the same Debian
system at the same time.  *That* is intolerable.

I don't care about the callback.  The package maintainers have the job
of deciding whether the packages implement the same ABI or not.
DECIDE.

If the answer is "yes", then they should both be drop-in replacements,
and Provide the same virtual package.

If the answer is "no", then they should install different files in the
Debian namespace and should not Conflict with each other.

DECIDE, and then do whichever.  But the current "solution" is utterly
unacceptible.  

Thomas


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

Re: insighttoolkit2 is now available

[Andreas Tille]

On Mon, 12 Sep 2005, bear wrote:


Thanks for your sponsor. I have added the "Uploads:" line in the control file
and fixed the bug in CMakeCache.txt.debian. The new packages are uploaded to
mentors.debian.net, namely

libinsighttoolkit2_2.2.0-2_i386.deb
libinsighttoolkit2-dev_2.2.0-2_all.deb
insighttoolkit2-examples_2.2.0-2_all.deb


Well, I'm only interested in the source of the packages because I definitely 
will
build the package myself before uploading.  For instance this reveals a problem
I would like to discuss here:

dh_shlibdeps -a
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg12.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg16.so not recognized
...

Do you have any idea what's the problem with these libraries?


Please recheck if it is OK. Thanks!


Further comments:

insighttoolkit2-examples:

   I guess you will have your reasons to put the examples into
  /usr/share/insighttoolkit2/examples
   But usually examples should be found in /usr/share/doc//examples
   and thus I would like you to place a symlink to this directory.

libinsighttoolkit2-dev:

   I wonder why a dev package is architecture all.  Normally it contains
   headers *and* static libraries but obviousely there are no static libraries
   builded at all.

libinsighttoolkit2:

   I have no idea about cmake but it is really necessary to move
 /usr/lib/InsightToolkit/*.cmake
   files into the binary package?

Kind regards and thanks for your work on ITK

 Andreas.

--
http://fam-tille.de


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

Re: curl situation is intolerable

[Paul TBBle Hampson]

On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote:
> Paul TBBle Hampson <[EMAIL PROTECTED]> writes:

>> Mind you, the license/OpenSSLCallback conflict neccessarily
>> segregates the packages into two camps, those which are GPL, and
>> those which need the callback only supplied by the OpenSSL-linked
>> libcurl.

> You misunderstand my complaint.

I suspect I did not, but I possibly misdirected my answer.

> What I complain is that, once the packages have been so segregated, it
> is now *impossible* to even install both kinds on the same Debian
> system at the same time.  *That* is intolerable.

I totally agree. Somehow the _current_ situation managed to be worse
than any of the three solutions I proposed.

And the dlopening of libldap.so bug is prolly still present, going by the
package long description...

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpGafDZIXuz9.pgp
Description: PGP signature