Re: Switching the default /bin/sh to dash

[Giacomo A. Catenazzi]

Raphael Geissert wrote:

dash already has one, the idea is to make it essential and default to yes,
so that as soon as it is installed the symlink is changed. If you wish to
have dash installed but not as /bin/sh you can always dpkg-reconfigure
dash.


Why essential? It doesn't provide anything dash-specific, and I hope
nobody will write a script starting with "#!/bin/dash".

I prefer that we handle it like the libraries:
make it "essential"-like via dependencies of true-essential packages.

ciao
cate

PS: I think that dash is a step toward a truly posix shell, but it
is not yet a posix shell: we still need fewer extentions. So
in five/ten year we will change it again.


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

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Philipp Kern]

On 2009-06-25, Bernd Eckenfels  wrote:
> In article <20090625100437.ga10...@ana.debian.net> you wrote:
>> FWIW, you will see plenty of national ID from all the european countries
>> in DebConf. I do expect most of germans, frenchs, italian, belgian, etc just
>> travelling with their cards. They do not need their passports to come.
> European ID cards are more like a passport, whereas a US ID is a driver
> license.  (In addition to that national driver licenses of european
> countries are much less usefull for this purpose unless they are the new
> euro-style license check cards)

But even then I don't think they are accepted as some sort of ID in Europe.

Kind regards,
Philipp Kern



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

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Cyril Brulebois]

Philipp Kern  (26/06/2009):
> On 2009-06-25, Bernd Eckenfels  wrote:
> > European ID cards are more like a passport, whereas a US ID is a
> > driver license.  (In addition to that national driver licenses of
> > european countries are much less usefull for this purpose unless
> > they are the new euro-style license check cards)
> 
> But even then I don't think they are accepted as some sort of ID in
> Europe.

Driver licenses? Depends. At least from my limited experience in France
with a French driver license, it's possible to be ID'd with it to pass
an exam, but not to vote. One reason I was given for the latter is that
the nationality isn't included on the driver license.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: BTS and the missing 'invalid' tag

[Frank Küster]

Michael Banck  wrote:

> On Sun, Jun 21, 2009 at 06:32:10PM +0100, Neil Williams wrote:
>> Which is precisely what I don't think we need. There is no difference
>> between "invalid" and "this is an invalid bug, closing". 
>
> Of course there is.  After the closed bug got archived, it's no longer
> displayed by default for a bug search.  So chances are that the next
> user encountering this non-bug will file it again.  

In this case, I'd tend to say that there is actually a bug: Move the
documentation that explains why the behavior is intended to a more
prominent, visible place.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: BTS and the missing 'invalid' tag

[Cyril Brulebois]

Frank Küster  (26/06/2009):
> In this case, I'd tend to say that there is actually a bug: Move the
> documentation that explains why the behavior is intended to a more
> prominent, visible place.

OK, and once that done, what do you do when the bugs keep on being
opened because people don't read the docs?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Web Design & Development /SEO Services

[Harish]

Dear Sir/Madam,

Are you looking for affordable website designing & development services?
Or want that your website should generate more traffic with high sales volume?

Look no further, as we have a reliable and experienced team to take care of 
your web related services like Website designing, development, redesigning, 
CMS, SEO, Online shopping
stores, ecommerce solutions, content writing and many other web services.

Website Designing & Development Services;
We are having an experienced team of web designers & developers and we offer 24 
hour support to our clients. We are based in New Delhi, India & have the advantage 
of offering high
end web solutions in affordable budget.

We specialize in;
1. Static websites (Html based websites)
2. Flash based websites & presentations.
3. Dynamic websites in PHP, ASP & .Net(ASPX).
4. Database driven websites.
5. E-commerce Solutions / Online Shopping Websites.
6. Product Catalogue Websites.
7. XML /AJAX integrated websites.
8. Content Management System (CMS)
9. Websites in DIV/CSS

Search Engine Optimization (SEO) Services;
Have you got your website optimized with the latest methodology LSI to get the 
maximum exposure in the search engines?
Is your website ranking low in the search engines or has less traffic?

Leave all your worries, because with our "Satisfaction Guarantee" we enable you to 
get the maximum return for the money that you spent on your SEO campaign. We follow Ethical 
&
White Hat SEO techniques to get your website rank high in the Search Engines on 
industry specific keywords.

Our SEO Package includes;
1. Analysis & Recommendations.
2. On-page Optimization.
3. Off-page Optimization.
4. Social Media Optimization.
5. Advanced Optimization.

We also offer custom made packages both for Website Design, Development & SEO 
services.

We guarantee High Rankings in Search Engines like Google, MSN & Yahoo on the 
1st to 10th positions.

Kind Regards,

Harish

P.S - This is the email sent by the individual and n0t by a robot. If do not 
wish to receive further emails, kindly reply back with the subject as 
Unsubscribe.





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

Bug#534686: ITP: python-tgext.admin -- user management controller add-on for TurboGears

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli 

* Package name: python-tgext.admin
  Version : 0.2.4
  Upstream Author : Christopher Perkins 
* URL : http://pypi.python.org/pypi/tgext.admin
* License : MIT
  Programming Lang: Python
  Description : user management controller add-on for TurboGears
   TurboGears2 is a framework to develop web applications in Python,
   according to the model-view-controller (MVC) architecture;
   tgext.admin is a controller add-on for TurboGears2 that provides a
   user interface to manage users, groups, and their permissions.
   .
   tgext.admin is compatible with the basic TurboGears2 identity
   model.

The package will be maintained under the umbrella of the Python
Modules Team.



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

Why does mysql-server depend on exim?

[mli...@stacktrace.us]

I just bootstrapped a fresh vm for some sandbox testing and came across the 
following issue.

While installing mysql-server I noticed the following dependencies:

"bsd-mailx exim4 exim4-base exim4-config exim4-daemon-light"

Although it's not that big of a deal, it does raise the question "Why should a 
database server require a MTA?"


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

Re: Why does mysql-server depend on exim?

[Rene Engelhard]

Hi,

mli...@stacktrace.us wrote:
> While installing mysql-server I noticed the following dependencies:
>
> "bsd-mailx exim4 exim4-base exim4-config exim4-daemon-light"
>
> Although it's not that big of a deal, it does raise the question "Why should 
> a database server require a MTA?"

It doesn't.

mysql-server is an empty package and depends on mysql-server-5.0.
Which *recommends* mailx.
And mailx *of course* depends on a MTA.

Install-recommends-per-default strikes again.

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


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

Re: Why does mysql-server depend on exim?

[Cyril Brulebois]

mli...@stacktrace.us  (26/06/2009):
> While installing mysql-server I noticed the following dependencies:
>
> "bsd-mailx exim4 exim4-base exim4-config exim4-daemon-light"
>
> Although it's not that big of a deal, it does raise the question "Why
> should a database server require a MTA?"

-(cy...@talisker pts/5)-(~)
$ LANG=C aptitude why mysql-server exim4
p   mysql-server Dependsmysql-server-5.0
p   mysql-server-5.0 Recommends mailx   
p   mailutilsProvides   mailx   
p   mailutilsDependsexim4 | mail-transport-agent

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: libswt and eclipse

[Adrian Perez]

I'm planning to adopt both. Essentially, what I need was azureus, but
then as a dependency I need to adopt swt-gtk. Since in the future I plan
to help maintaining eclipse, since it's orphaned right now, then I'm
killing two birds in one shot here. 

Best regards.

On Thu, 2009-06-25 at 23:03 +0200, Adnan Hodzic wrote:
> Adrian,
> 
> Are you planning to adopt both azureus and swt-gtk, or just swt-gtk?
> 
> Adnan
> 
> On Thu, 2009-06-25 at 15:12 -0400, Adrian Perez wrote:
> > Ok, I was expecting to upload it later, but since I got the answers from
> > the maintainer, then I'll upload it for weekend review to
> > mentors.debian. I know there's work to do still, but I've tested the
> > packages, they install-purge gracefully, are almost lintian-clean
> > (besides the fact that gives me debhelper-no-misc-depends). I've made a
> > few hello-world-kind of program using SWT without any compile or runtime
> > errors. Please keep an eye on it. I'll be working on it at the weekend
> > too, so if you could give your points earlier, that would be great.
> > 
> > On Thu, 2009-06-25 at 09:15 -0700, Shaun Jackman wrote:
> > > Hi Adrian,
> > > 
> > > I maintain SWT (swt-gtk) for Debian. If you send me the diff and dsc,
> > > I'll look over your work this weekend. Adnan Hodzic was also
> > > interested in adopting swt-gtk and azureus. If you like, you could
> > > collaborate with him. Thanks for considering adopting swt-gtk and
> > > azureus. They could use a maintainer that uses Azureus more frequently
> > > than I do.
> > > 
> > > Cheers,
> > > Shaun
> > > 
> > > 2009/6/25 Adrian Perez :
> > > > Thanks for your reply.
> > > > I know I could upload to mentors. But since it's quite ethical to
> > > > request the maintainer's feedback before adopting a package, I was
> > > > asking because I have no way of establishing contact with him, since
> > > > I've tried a lot in the last days.
> > > >
> > > > I'm currently doing some refinements, and planning to add the x86_64
> > > > and ppc versions as arch-patches.
> > > >
> > > > I think the previous maintainer could sponsor it, but because he is
> > > > probably off, then I should RFS it.
> > > >
> > > > Thank you all. Feedback welcome.


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

Re: C++ symbol mangling difference between arches

[Modestas Vainius]

Hello,

On 2009 m. June 26 d., Friday 02:02:48 Ben Hutchings wrote:

> > - it's probably impossible to have substitutions to cover all cases
> >   for C++ symbol mangling... do you believe that it is possible
> >   to have enough (stable) substitutions to cover most common cases?
> >
> >   (in the current patch there is ssize_t, size_t, int64_t, uint64_t,
> >   qreal and vt= for C++ virtual table offset)
>
> [...]
>
> The implementation of the substitution vt= seems to be intended to
> cover virtual function thunks, but I think it is wrong.
>
> First, some background.  In a class with multiple bases, all but one
> base class instance must be offset from the address of the derived class
> instance.  If the derived class overrides a virtual function from one of
> these bases, the compiler must generate a wrapper function, a "virtual
> function thunk", which subtracts that offset from the "this" pointer
> before calling the implementation.  In the case of virtual inheritance,
> a more complex adjustment is necessary.

Ok, I agree with you, there is no direct relation of *2 in case of non 
virtual offsets. So the name 'vt' is actually very misleading as it is now. It 
could rather be something like ptr= (aka pointer) (4 on 32bit arches, 8 
on 64bit arches mutipled by =1 by default) which would be 100% correct. 
However, in practise ptr may be actually enough for some (most?) classes 
because:

1) In order to keep binary compatibility, the base class can neither shrink 
nor grow. Hence techniques like d-pointer are frequently used for public ABI 
stable classes to workaround this limitation. So if the base class contains 
only a d-pointer (or more pointers) and an internal pointer to the virtual 
table, ptr will be enough.

2) However, nothing prevents the d-pointer based class to contain data members 
which are never going to be removed (like int x, y in Coord class). Then the 
ptr is no longer valid for such non virtual offsets.

2a) The subst can be like vt=+ (e.g. vt=8+4), where 
constant_size (default to 0) is constant on each arch while  would 
vary according to the pointer size. vt=8+4 would be 12 on 32bit arches and 16 
on 64bit arches. 

2b) Still 2a is not enough if the base class contains such data members like 
(s)size_t (on s390) or qreal (on armel). To support such cases, vt can only be 
a complex expression with recursive subst expansion like 
vt=size_t*2+ptr*2+qreal+4. But do we want this? The alternative would be to 
maintain such symbols (like destructors) as arch specific.

If I understand correncly, this adjustment is only needed in case of multiple 
inheritance only for virtual functions of the same name which are in multiple 
base classes and they are overriden in the derived class. Unfortunately, 
virtual destructors satisfy those conditions in any case of multiple 
inheritance and good style of C++ programming :/ So this issue is important.

So which way to choose: 2a or 2b or another?

> The symbol names for virtual function thunks include a description of
> the adjustment, taking the form:
>
> "Th" 
> or  "Tv"  "_" 
>
> Since the  depends on the sizes of base classes,
> there is no simple relationship between its values on different
> architectures.  This may be true for the  as well but
> I'm not sure.

I'm also not so sure about  but hopefully it is more rare than 
. I guess ptr should always be enough for it.

> There's also a nasty possibility that on some architectures two
> parameter types could be identical and so the second instance would be
> represented by a back-reference ("S_" or "S"  "_"), whereas on
> others they would be different and the second would be represented
> independently.

There is definitely no need to support such cases via substitutions because
they are rare and arch specific symbols look like a perfect workaround 
(solution?). Also dpkg-gensymbols is never going to add substitutions (or any 
other symbol tags), this will solely be responsibility of the maintainer or 
some external tool.

-- 
Modestas Vainius 


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

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Kurt Roeckx]

On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:
> 
> This could be very bad for the root-system package set.   ROOT has
> libraries named like libMatrix, libPostscript, libPhysics, libMath, and
> so on - i.e., very general names.   For that reason I moved all the
> packages into the subdirectory /usr/lib/root to not cause possible
> conflicts.   To make this work seamlessly for both the root-system
> binaries and user code linked against the libraries, I dump a file
> in /etc/ld.so.conf.d/.  
> 
> For the root-system binaries, there is of course the option to link with
> RPATH set.   However, I believe that the Policy actually forbids this.  

I see no reason why policy should forbid rpath's for that case.
What we don't want is an rpath for "/usr/lib".  But an rpath
for "/usr/lib/root" would be the right thing to do for
libraries/binaries from the root system.


Kurt


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

Re: Visiontek ATI Radeon "All-In-Wonder" Delux card

[Daniel James]

Hi John,


Any one here using this card effectively with Linux?


It would help to know which chipset this card uses, there are many 
different Radeon cards offered by that manufacturer:


http://graphics.visiontek.com/video/4000/4870x2.html

When you find out, I suggest looking up that chipset on:

http://www.free3d.org/

Cheers!

Daniel


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

Re: Switching the default /bin/sh to dash

[Christian Perrier]

Quoting Luk Claes (l...@debian.org):

> It's enough to dpkg-reconfigure dash for existing installations.


And, by the way, if the switch happens, one has to think about
rewording the current debconf template for dash, that says:

Description: Install dash as /bin/sh?
 The default /bin/sh shell on Debian and Debian-based systems is bash.
 .
 However, since the default shell is required to be POSIX-compliant,
 any shell that conforms to POSIX, such as dash, can serve as /bin/sh.
 You may wish to do this because dash is faster and smaller than bash.


If dash becomes the default /bin/sh, then that template should be kept
with a different wording (for those who might want to restore it as
the default sh) and a similar template (and maintainer script magic)
should be added to bash.



signature.asc
Description: Digital signature

Re: Bug#534507: ITP: kalternatives -- graphical alternatives system configuration tool

[Guillem Jover]

Hi Pino!

On Thu, 2009-06-25 at 01:02:12 +0200, Pino Toscano wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pino Toscano 
> 
> * Package name: kalternatives
>   Version : 0.12
>   Upstream Author : Pino Toscano 
> * URL : 
> http://kde-apps.org/content/show.php/Kalternatives?content=16016
> * License : GPL
>   Programming Lang: C++
>   Description : graphical alternatives system configuration tool
> 
>  Kalternatives offers a GUI to configure the alternative systems (a
>  system that allows you to select one alternative file for many in the
>  filesystem).
>  .
>  This is an advanced GUI of the update-alternatives program shipped with dpkg.

I've skimmed over the sources, and it seems kalternatives is reading
and writting directly to the alternatives db (under
/var/lib/dpkg/alternatives/). The db should be considered internal,
and we reserve the right to change its layout in the future.

There's been recent changes to update-alternatives to make it more
friendly and usable by front-ends (specifically the --get/set-selections
and --query options), could you consider rewritting it using those?
If the interface is inadequate or too limited we can always extend/fix
it.

Another option would be to wait a bit, the future plans are to
rewrite it in C and move part of the db handling to a shared library.

thanks,
guillem


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

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Russ Allbery]

Kurt Roeckx  writes:
> On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:

>> This could be very bad for the root-system package set.  ROOT has
>> libraries named like libMatrix, libPostscript, libPhysics, libMath,
>> and so on - i.e., very general names.  For that reason I moved all
>> the packages into the subdirectory /usr/lib/root to not cause
>> possible conflicts.  To make this work seamlessly for both the
>> root-system binaries and user code linked against the libraries, I
>> dump a file in /etc/ld.so.conf.d/.

>> For the root-system binaries, there is of course the option to link
>> with RPATH set.  However, I believe that the Policy actually forbids
>> this.

> I see no reason why policy should forbid rpath's for that case.  What
> we don't want is an rpath for "/usr/lib".  But an rpath for
> "/usr/lib/root" would be the right thing to do for libraries/binaries
> from the root system.

Currently, I don't think Policy says anything about RPATH.  It does say:

 Shared object files (often `.so' files) that are not public
 libraries, that is, they are not meant to be linked to by third
 party executables (binaries of other packages), should be installed
 in subdirectories of the `/usr/lib' directory.  Such files are
 exempt from the rules that govern ordinary shared libraries, except
 that they must not be installed executable and should be
 stripped.[5]

Perhaps that's not quite the definition of "not public" we want?

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


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

Re: C++ symbol mangling difference between arches

[Ben Hutchings]

On Fri, Jun 26, 2009 at 04:34:00PM +0300, Modestas Vainius wrote:
[...]
> 2b) Still 2a is not enough if the base class contains such data members like 
> (s)size_t (on s390) or qreal (on armel). To support such cases, vt can only 
> be 
> a complex expression with recursive subst expansion like 
> vt=size_t*2+ptr*2+qreal+4. But do we want this? The alternative would be to 
> maintain such symbols (like destructors) as arch specific.
 
Also there are differences in alignment requirements between 32-bit
architectures.  For example i386 aligns 64-bit types on 32-bit boundaries
whereas armel aligns them on 64-bit boundaries.

> If I understand correncly, this adjustment is only needed in case of multiple 
> inheritance only for virtual functions of the same name which are in multiple 
> base classes and they are overriden in the derived class.

The virtual function name has nothing to do with it.  The adjustment is
needed whenever instances of the base class that first defined the
virtual function are not the first sub-object in instances of the
derived class.

> Unfortunately, virtual destructors satisfy those conditions in any case of
> multiple inheritance and good style of C++ programming :/ So this issue is
> important.
> 
> So which way to choose: 2a or 2b or another?
[...]

Would it be possible to implement expansion to a regexp instead of to a
string that must exactly match?

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


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

Re: C++ symbol mangling difference between arches

[Modestas Vainius]

Hello,

On 2009 m. June 26 d., Friday 19:43:13 Ben Hutchings wrote:
>
> Would it be possible to implement expansion to a regexp instead of to a
> string that must exactly match?

I think yes if there is no other way (and according to your answers, there 
really isn't). Symbol files have two usage scenarios in my mind:

1) Smart symbol based shlibs management (primary goal).
2) Tracking ABI breakages (side effect).

However, the second has never been entirely true neither for C (e.g. function 
parameter / return type changes cannot be detected) nor C++ (e.g. class size 
changes are not detected while function parameter changes are (sort of)). 
Adding regexps would make ABI tracking even more relaxed.

While apparently, VT can't be implemented differently (except \d+), what about 
size_t etc. then? They all can be implemented as regexps too the most simple 
being 'any character'. However, in my opinion, exact string matching is 
worthwhile to keep whenever possible.

Also, this rises another question if dpkg-gensymbols should handle VT symbols 
automagically since they (typically) can be autodetected (unless they are 
compressed):

^_ZThn?\d+
^_ZTvn?\d+_n?\d+
^_ZTC - AKA construction vtable, but it is rather complex to detect where the 
offset is in this one, e.g.: _ZTCN6KParts15DockMainWindow3E56_NS_8PartBaseE
   ^^

Raphael, should I provide a patch for regexp support + {vt} subst as implicit 
\d+ regexp?

-- 
Modestas Vainius 


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

Re: Switching the default /bin/sh to dash

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:

> PS: I think that dash is a step toward a truly posix shell, but it is
> not yet a posix shell: we still need fewer extentions. So in five/ten
> year we will change it again.

I doubt that we're going to move in that direction farther than where
dash already is.  The extensions that are left in dash are by and large
things that people really want to use and that are helpful in practical
ways for writing reasonable scripts.

I think it's more likely that POSIX will end up adopting some of those
extensions.  (I certainly hope this will happen for things like test -a.)

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


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

Re: Architectures (Operating Systems and CPU Architectures)

[Jonathan Yu]

Russ and Steve:

Thank you both for your replies.

I'm going to have to spend some time considering what you have both
said, and try to devise a clever way of representing the platform
information. In terms of maintainability I don't think I have much of
a problem there, since I'm using a Perl script that loads Dpkg::Arch
and gets architecture information the same way `dpkg-architecture -L'
does, and writes corresponding C code. It does mean I'll have to
update code if there are new accepted platforms, but I'm prepared to
do so. I don't anticipate it'll happen all too often anyway.

I understand the syntax and semantic differences here. I am writing a
parser for control files, and I'd like it to accept any valid syntax,
but at least warn people if there is invalid semantics, using the
information culled from dpkg-architecture.

At the very least, such a feature will give developers a warning that
they made a typo in an architecture name, which could prevent a
disaster further down the road.

Thanks again for all of your help with the various issues. I
particularly appreciate Russ' patience explaining things to me
clearly, and considering my ideas too.

Cheers,

Jonathan

On Fri, Jun 26, 2009 at 12:56 AM, Steve Langasek wrote:
> On Thu, Jun 25, 2009 at 07:23:58PM -0700, Russ Allbery wrote:
>> > My question is, does anyone know of cases where a given operating
>> > system and architecture does not constitute a valid platform (ie,
>> > Architecture in the d/control file sense).
>
>> armel and lpia are special cases and don't combine with other kernels
>> from dpkg's perspective, which explains your count difference.  I forget
>> off-hand why this is.
>
> "armel" is a Linux-specific successor to "arm" with a different ABI.
>
> "lpia" is arguably appropriate to pair with other kernels beside Linux since
> the instruction reordering is not Linux-specific, so perhaps excluding lpia
> was an oversight.
>
> --
> 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 Developer                                    http://www.debian.org/
> slanga...@ubuntu.com                                     vor...@debian.org
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: C++ symbol mangling difference between arches

[Florian Weimer]

* Modestas Vainius:

> While apparently, VT can't be implemented differently (except \d+),
> what about size_t etc. then? They all can be implemented as regexps
> too the most simple being 'any character'. However, in my opinion,
> exact string matching is worthwhile to keep whenever possible.

Can't you ship the demangled names in the symbols file?  I suppose
this would make rewriting easier.


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

Re: Switching the default /bin/sh to dash

[Steve Langasek]

On Wed, Jun 24, 2009 at 10:21:45PM -0500, Raphael Geissert wrote:
> I just noticed I forgot to say something:

> > What won't change:
> > * Bash will still be used as the default interactive shells for users
> * the sh symlink won't be modified on existing installations

I understand the concerns about not breaking existing scripts, but I'll
nevertheless be disappointed if this switch isn't made on upgrades as well.
Using bash as /bin/sh causes a number of subtle problems for shutdown
sequences, in addition to the obvious performance issues, and I think the
fix for non-POSIX shell scripts is straightforward enough that we should
just document the change (in the release notes and NEWS.Debian) and tell
users to use the right interpreter if they have any doubts about their
dash-compatibility.

We certainly make much more intrusive changes to the implementations of
other interpreters across releases, and while none of these have quite the
same penetration as /bin/sh, I think weighing the scope of the changes vs.
the number of scripts puts this on the same order as past updates to
/usr/bin/perl or /usr/bin/python.

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


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

[VAC] July - August

[David Paleino]

Hello,
I did hope I could've sent this mail in a better situation, but my DSL
unexpectedly stopped working a bit ago, so I'm anticipating my [VAC] message by
a couple of hours :)

I'm moving to the seaside home, and will probably have from limited to no
connection at all, for July-August. Please feel free to NMU my packages: those
I maintain alone are maintained in collab-maint's git (some older packages are
still in SVN): *please* do commit your changes in the proper $VCS when NMUing.

I'll try to process my mails in batch mode, hopefully I'm going to get a
GPRS/UMTS/whatever connection, but that's not for sure.

If anyone is coming here, that is Marsala - Mazara del Vallo - Castelvetrano
(Sicily) or nearby for the summer (I'm in Mazara), we could arrange a meeting
(keysigning? coffee? chat? whatever :)). Please drop me a mail if you wish.

In any case, happy summer hacking!
David

P.S.: sorry if d-d@ is not the right list to write a [VAC] message, but
ENOMONEY to google where the right list is :) (connecting with my mobile
without any special plan for data... argh)

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Bug#534750: ITP: telepathy-mission-control-5 -- management daemon for Telepathy real-time communication framework

[Simon McVittie]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: telepathy-mission-control-5
  Version : 5.1.2
  Upstream Author : the Telepathy project (© Nokia Corporation, Collabora Ltd.)
* URL : http://mission-control.sourceforge.net/
* License : variously LGPL (= 2.1) and LGPL (>= 2.1)
  Programming Lang: C with GObject
  Description : management daemon for Telepathy real-time communication 
framework

Telepathy Mission Control 5 is an account manager and channel dispatcher for
the Telepathy framework, allowing user interfaces and other clients
to share connections to real-time communication services without conflicting.
It implements the AccountManager and ChannelDispatcher D-Bus APIs as described
by telepathy-spec.

The account manager part stores real time communication account details,
connects to the stored accounts on request, and sets the accounts' presence,
nickname and avatar according to requests from Telepathy user interfaces and
other components.

The channel dispatcher part responds to incoming communication channels
(message streams, voice/video calls, file transfers etc.) by dispatching
them to suitable user interfaces, and requests outgoing communication
channels according to requests from a Telepathy UI.

This is not a compatible replacement for Mission Control 4 (in the
telepathy-mission-control package), but they can be installed in parallel.

- --

Notes regarding this ITP:
* MC 4 will be removed when the programs that use it (I think that's just
  Empathy) have been ported to MC 5. That porting will take a while, though,
  so this is a new source package and the versions will exist in parallel for
  a bit.
* There's packaging for 5.1.0 on git.debian.org already; I just need to update
  it for a couple of new upstream releases, which should be pretty easy.
-BEGIN PGP SIGNATURE-

iD8DBQFKRThFWSc8zVUw7HYRAjStAJ9If6vzQb7oX2Tcxr52CQjpK5glhwCg8D+e
ZN69rkuCKHJt9rVE1lSIfpQ=
=KExX
-END PGP SIGNATURE-



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

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Steve Langasek]

On Mon, Jun 22, 2009 at 02:41:09PM +0200, Christian Holm Christensen wrote:
> > I understand this issue, but putting libMatrix in /usr/lib/root avoid file
> > conflict with other package, do not address the problem of library name
> > conflict at run-time.

> Agreed.  Suppose you have packages bar and baz, both of which contain
> /usr/lib/libfoo.so.1.  If bar "Conflict"s with baz or vice versa, then
> both of them cannot be installed at the same time, and there will only
> be one possible /usr/lib/libfoo.so.1 on the system.   Now suppose the
> package gnus comes along, which also provides /usr/lib/libfoo.so.1, then
> both bar and baz needs to "Conflict" with gnus, or gnus has to conflict
> with bar and baz.   I guess it is an N! problem. 

If all of these libfoo.so.1 files implement the same interface, why does
someone ever need to have more than one of them installed at a time?  In
that case, Conflicts: is reasonable; and you can use a mutually agreed-upon
virtual package (Conflicts/Replaces/Provides) to solve the N! problem.

If they don't implement the same interface, then why are they using the same
name?  In this case they should solve the conflicts by using distinguished
sonames, not merely different paths for the library, to avoid accidental
library path collisions.

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


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

Re: Bug#519941: Remove Policy permission for packages to modify ld.so.conf

[Steve Langasek]

On Fri, Jun 26, 2009 at 04:59:26PM +0200, Kurt Roeckx wrote:
> > For the root-system binaries, there is of course the option to link with
> > RPATH set.   However, I believe that the Policy actually forbids this.  

> I see no reason why policy should forbid rpath's for that case.

For the standard reason that rpath is bad: it breaks when library paths
change, as will hopefully happen soon with multiarch. :)

> What we don't want is an rpath for "/usr/lib".  But an rpath
> for "/usr/lib/root" would be the right thing to do for
> libraries/binaries from the root system.

Yes, it's the least-bad option in this case, in spite of the knock-on
problems.

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


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

Bug#534751: ITP: latex2mathml -- Convert LaTeX math formulas to MathML

[Jeremy Oden]

Package: wnpp
Severity: wishlist
Owner: Jeremy Oden 


* Package name: latex2mathml
  Version : 0.0.0
  Upstream Author : Jeremy Oden 
* URL : https://sourceforge.net/projects/latex2mathml/
* License : BSD
  Programming Lang: PHP
  Description : Convert LaTeX math formulas to MathML

 latex2mathml is a powerful php5 class that can be used to 
 convert LaTeX math formulas to Presentation MathML.
 This program can be used as command line, using php5-cli.



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

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Gunnar Wolf]

David Moreno dijo [Thu, Jun 25, 2009 at 09:27:28AM -0400]:
> >> Driving licenses are expressly not accepted as official ID documents
> >> in Mexico, even if they are government-issued.
> >
> > That just begs the question: official to whom, and why?
> 
> Official for the government for procedures such as state and federal  
> elections or to prove citizenship to get passport.

...Or as an acceptable identification to handle your money at the
bank, or to make government tramits, or... 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Bug#534768: ITP: libbarby-ruby -- Pure-Ruby barcode generator

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: libbarby-ruby
  Version : 0.3.1
  Upstream Author : Tore Darell 
* URL : http://toretore.github.com/barby
* License : MIT/X
  Programming Lang: Ruby
  Description : Pure-Ruby barcode generator

Extensible, complete library to generate barcodes, implemented purely
in Ruby. Implements all major 1D (and, via rqrcode, some 2D) barcode
standards, and can generate its output in a variety of formats.



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

Bug#534769: ITP: librqrcode-ruby -- Pure-ruby QR Code (2D barcode) generator

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 

* Package name: librqrcode-ruby
  Version : 0.3.2
  Upstream Author : Duncan Robertson 
* URL : http://whomwah.com/rqrcode/
* License : MIT/X
  Programming Lang: Ruby
  Description : Pure-ruby QR Code (2D barcode) generator

rQRCode is a library for encoding QRCodes in Ruby. It has a simple
interface with all the standard qrcode options. It was adapted from
the Javascript library by Kazuhiko Arase.



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

Re: C++ symbol mangling difference between arches

[Modestas Vainius]

Hello,

On 2009 m. June 26 d., Friday 23:01:54 Florian Weimer wrote:
> * Modestas Vainius:
> > While apparently, VT can't be implemented differently (except \d+),
> > what about size_t etc. then? They all can be implemented as regexps
> > too the most simple being 'any character'. However, in my opinion,
> > exact string matching is worthwhile to keep whenever possible.
>
> Can't you ship the demangled names in the symbols file?  I suppose
> this would make rewriting easier.

While it is a good idea worth consideration but I think demangled symbol
names are somewhat too ambiguous to be used in general. See below:

$ grep '^ ' /var/lib/dpkg/info/libphonon4.symbols | c++filt | sort | uniq -c | 
grep '^[[:space:]]*[2-9]' | sort -n
  2  non-virtual thunk to 
Phonon::AbstractAudioOutput::~AbstractAudioOutput()@Base 4:4.2.0
  2  non-virtual thunk to Phonon::Effect::~Effect()@Base 4:4.2.0
  
  2  non-virtual thunk to Phonon::EffectWidget::~EffectWidget()@Base 
4:4.2.0  
  2  non-virtual thunk to 
Phonon::Experimental::Visualization::~Visualization()@Base 4:4.2.0
  2  non-virtual thunk to Phonon::MediaObject::~MediaObject()@Base 4:4.2.0  

  2  non-virtual thunk to Phonon::SeekSlider::~SeekSlider()@Base 4:4.2.0

  2  non-virtual thunk to Phonon::VideoPlayer::~VideoPlayer()@Base 4:4.2.0  

  2  non-virtual thunk to Phonon::VolumeSlider::~VolumeSlider()@Base 
4:4.2.0
  2  
Phonon::AbstractAudioOutput::AbstractAudioOutput(Phonon::AbstractAudioOutputPrivate&,
 QObject*)@Base 4:4.2.0
  2  
Phonon::AbstractMediaStream::AbstractMediaStream(Phonon::AbstractMediaStreamPrivate&,
 QObject*)@Base 4:4.2.0
  2  Phonon::AbstractMediaStream::AbstractMediaStream(QObject*)@Base 
4:4.2.0 
  2  
Phonon::AbstractVideoOutput::AbstractVideoOutput(Phonon::AbstractVideoOutputPrivate&)@Base
 4:4.2.0  
  2  Phonon::AudioOutput::AudioOutput(Phonon::Category, QObject*)@Base 
4:4.2.0   
  2  Phonon::AudioOutput::AudioOutput(QObject*)@Base 4:4.2.0
 
  2  Phonon::Effect::Effect(Phonon::EffectPrivate&, QObject*)@Base 4:4.2.0  
 
  2  
Phonon::Effect::Effect(Phonon::ObjectDescription<(Phonon::ObjectDescriptionType)1>
 const&, QObject*)@Base 4:4.2.0
  2  Phonon::EffectParameter::~EffectParameter()@Base 4:4.2.0   
  
  2  Phonon::EffectParameter::EffectParameter()@Base 4:4.2.0
  
  2  Phonon::EffectParameter::EffectParameter(int, QString const&, 
QFlags, QVariant const&, QVariant 
const&, QVariant const&, QList const&, QString const&)@Base 4:4.2.0   
  
  2  Phonon::EffectParameter::EffectParameter(Phonon::EffectParameter 
const&)@Base 4:4.2.0   
  2  Phonon::EffectWidget::EffectWidget(Phonon::Effect*, QWidget*)@Base 
4:4.2.0  
  2  
Phonon::Experimental::AbstractAudioDataOutput::AbstractAudioDataOutput()@Base 
4:4.3.0   
  2  
Phonon::Experimental::AbstractVideoDataOutput::AbstractVideoDataOutput()@Base 
4:4.3.0   
  2  
Phonon::Experimental::AbstractVideoDataOutput::AbstractVideoDataOutput(Phonon::Experimental::AbstractVideoDataOutputPrivate&)@Base
 
4:4.3.0 
  
  2  Phonon::Experimental::AudioDataOutput::AudioDataOutput(QObject*)@Base 
4:4.2.0   
  2  Phonon::Experimental::AvCapture::AvCapture(QObject*)@Base 4:4.3.0  
 
  2  
Phonon::Experimental::MediaSource::MediaSource(Phonon::Experimental::MediaSource
 const&)@Base 4:4.2.0   
  2  
Phonon::Experimental::MediaSource::MediaSource(Phonon::ObjectDescription<(Phonon::ObjectDescriptionType)65536>
 const&)@Base 
4:4.2.0 
  2  
Phonon::Experimental::MediaSource::MediaSource(QList 
const&)@Base 4:4.2.0  
  2  
Phonon::Experimental::VideoDataOutput2::VideoDataOutput2(QObject*)@Base 4:4.3.0 

  2  Phonon::Experimental::VideoDataOutput::VideoDataOutput(QObject*)@Base 
4:4.2.0   
  2  Phonon::Experimental::Visualization::Visualization(QObject*)@Base 
4:4.2.0   
  2  Phonon::GlobalConfig::GlobalCon