Re: Do symbols make sense for C++

2012-01-26 Thread Mike Hommey 
On Thu, Jan 26, 2012 at 08:58:55AM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 25 Jan 2012, Russ Allbery wrote:
> > 4. Once I had a symbols file that resulted in a successful build and that
> >I could have uploaded, I started thinking about how I was going to
> >maintain it.  With a C program, I would change the symbols file
> >versions when the underlying function implementation changes in a way
> >that may not offer eqiuvalence, similar to bumping shlibs.  I realized
> >that I was going to have no idea when that happened, and the only way
> >that I would maintain the symbols file would be to either trust
> >upstream to maintain ABI equivalence and therefore only change the
> >symbols file when upstream changes the SONAME, or not trust upstream to
> >maintain ABI equivalence and therefore change all the versions with
> >each new upstream release.  That gives me exactly the same semantics as
> >a shlibs file, so what's the point in having a symbols file?
> 
> The main benefit of the symbols file is that new symbols (API extension)
> are listed with the version where they have been introduced. So that
> seriously reduces the number of packages which would be affected by the
> equivalent shlibs bump.
> 
> Otherwise I agree with you, maintainers of C++ libs are unlikely to be
> able to (preemptively) detect when a given symbol should have had its
> version bumped... so you should really trust upstream and hope to catch
> API extension that preserve ABI in the upstream changelog.
> 
> > 5. The exported symbols of the library contained many symbols that
> >obviously weren't really from that library, but instead were artifacts
> >of the C++ compilation process, things like instantiations of
> >std::vector.  Do those go into the symbols file?  Do they change from
> >architecture to architecture?  If they disappear again, is that
> >actually an ABI break?  How do I know?  It's all very mysterious, and
> >while shlibs provides the same semantics as just ignoring this, at
> >least I'm not then including in the package data, generated by me,
> >things that I'm just blindly ignoring.
> 
> It's also very mysterious to me. :) But Modestas Vainius has still managed
> to maintain symbols files for many KDE libraries. He might be able to tell
> you more.

Chances are KDE libraries are using visibility flags when compiling,
which limits the number of exported symbols.

Mike


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

Re: Do symbols make sense for C++

2012-01-26 Thread Mike Hommey 
On Wed, Jan 25, 2012 at 10:53:04PM -0800, Russ Allbery wrote:
> I'm currently working on the Policy modification to document (and
> recommend) use of symbols instead of shlibs, but I'd only personally used
> symbols with C libraries.  Today I decided that I should try adding a
> symbols file to a C++ library, particularly if I'm going to recommend
> everyone do it.  I tried this exercise with xml-security-c, which is, I
> think, a reasonably typical C++ library.  Not the sort of core C++ library
> that would sit at the center of the distribution, but a random software
> package that's in Debian because other things use it.
> 
> The experience was rather interesting, and I ended up uploading the new
> version without a symbols file and continuing to just use shlibs.  That's
> for the following reasons:
> 
> 1. The generated symbols file was HUGE.  Hundreds of lines.  This is a
>marked difference from the typical C symbols file, which is of quite
>manageable size.  Some of that is that the library provides a lot of
>different classes, but some of it is that C++ just generates a lot of
>exported symbols.  There's no way that I could do what I would do with
>a C library and understand those symbols, why they're there, and
>whether they are likely to have changed between revisions.
> 
> 2. Generating a reasonable symbols file was a pain.  Generating an
>unreasonable symbols file that just contains all of the mangled symbols
>is largely mechanical and uninteresting, but that symbols file doesn't
>seem to me to convey useful information.  So I did some scripting to
>translate the symbols back with c++filt, and add (c++) tags, and then
>try to understand what I was looking at and figure out whether I should
>sort the symbols list because the default sort is by mangled name,
>which is meaningless.  This is a rather unappealing process.  It's not
>particularly difficult, but it's very awkward and feels like it's
>missing vital tools.
> 
> 3. The resulting symbols file is incomprehensible to someone without
>strong knowledge of C++.  It's full of opaque entries that don't make
>sense to the non-C++ programmer, wihch I suspect is a substantial
>number of people who package C++ libraries for Debian.  I know enough
>C++ from school that I can evaluate security fixes, make simple
>patches, and review upstream changes, and I think that's all that
>should be needed to package things for Debian.  But I'm deeply
>uncomfortable producing a symbols file on my own that contains entries
>for things that I know nothing about and cannot evaluate when they've
>last changed, like "non-virtual thunk to FooClass::~FooClass@Base".
> 
> 4. Once I had a symbols file that resulted in a successful build and that
>I could have uploaded, I started thinking about how I was going to
>maintain it.  With a C program, I would change the symbols file
>versions when the underlying function implementation changes in a way
>that may not offer eqiuvalence, similar to bumping shlibs.  I realized
>that I was going to have no idea when that happened, and the only way
>that I would maintain the symbols file would be to either trust
>upstream to maintain ABI equivalence and therefore only change the
>symbols file when upstream changes the SONAME, or not trust upstream to
>maintain ABI equivalence and therefore change all the versions with
>each new upstream release.  That gives me exactly the same semantics as
>a shlibs file, so what's the point in having a symbols file?
> 
> 5. The exported symbols of the library contained many symbols that
>obviously weren't really from that library, but instead were artifacts
>of the C++ compilation process, things like instantiations of
>std::vector.  Do those go into the symbols file?  Do they change from
>architecture to architecture?  If they disappear again, is that
>actually an ABI break?  How do I know?  It's all very mysterious, and
>while shlibs provides the same semantics as just ignoring this, at
>least I'm not then including in the package data, generated by me,
>things that I'm just blindly ignoring.

6. Different levels of optimizations lead to different exported symbols,
   depending on whether some things are inlined or not. Different
   architectures may also have different exported symbols.

Mike


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

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Russ Allbery  wrote:
> But that feels like a result contrary to what I had previously thought was
> the intended direction, so I wanted to ask the Debian development
> community as a whole: am I missing something?  Are these symbols files
> actually useful? 

Symbol files are nice if you have a upstream who doesn't always take
binary compatibility that serious (which is probably the case for 75% of
upstreamers). Then you have a list that helps you finding out.

(and then of course there is the usual bits and pieces about why symbol
files are useful)

You do need a bit of knowledge, especially when some of the symbols you
mentioned go missing (like the std::vector ones), which isn't normally a
abi break.

>Am I missing some trick to make them useful?

You miss pkgkde-symbolshelper written by the fabulous Modestas Vainius
which is available in pkg-kde-tools.

http://pkg-kde.alioth.debian.org/symbolfiles.html

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji22f7.p7v.nos...@sshway.ssh.pusling.com

Re: Do symbols make sense for C++

2012-01-26 Thread Russ Allbery 
Raphael Hertzog  writes:
> On Wed, 25 Jan 2012, Russ Allbery wrote:

>> 4. Once I had a symbols file that resulted in a successful build and that
>>I could have uploaded, I started thinking about how I was going to
>>maintain it.  With a C program, I would change the symbols file
>>versions when the underlying function implementation changes in a way
>>that may not offer eqiuvalence, similar to bumping shlibs.  I realized
>>that I was going to have no idea when that happened, and the only way
>>that I would maintain the symbols file would be to either trust
>>upstream to maintain ABI equivalence and therefore only change the
>>symbols file when upstream changes the SONAME, or not trust upstream to
>>maintain ABI equivalence and therefore change all the versions with
>>each new upstream release.  That gives me exactly the same semantics as
>>a shlibs file, so what's the point in having a symbols file?

> The main benefit of the symbols file is that new symbols (API extension)
> are listed with the version where they have been introduced. So that
> seriously reduces the number of packages which would be affected by the
> equivalent shlibs bump.

My impression is that it's more difficult (not impossible, but more
difficult) to maintain a C++ library in that fashion the way that one
would maintain a C library, where one adds new symbols without requiring
an SONAME change.

Certainly, with the three C++ libraries that I maintain, upstream has a
policy of not even attempting to do this.  Bug fixes are made in an
ABI-compatible way and should not, as I understand it, involve anything
that would change the symbols file, and all other releases change the
SONAME.

I certainly believe there are carefully-maintained C++ libraries that are
more conservative and that go to the required effort to make this work
properly, and KDE is probably an excellent example of a large C++ project
with enough C++ experts involved to do this properly.  But I'm wondering
how many packages we really have like that.  By all means, if the library
makes that possible, maintain symbols!  But the library I looked at is
fairly typical, I think, in that the maintainers are not deeply attuned to
maintaining consistency of the export list in anything other than patch
releases.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwf2x4uu@windlord.stanford.edu

RE: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Richard Sweeney 

> > The code is GPL and the gfx and data is CC BY-NC-SA 3.0.
> 
> This is the first time I've heard a mention of a CC license. There is nothing
> in the source tarball mentioning a Creative Commons license. If you really 
> mean
> it to be CC BY-NC-SA 3.0, you have to clearly specify that in the source and
> binary packages you are distributing.
>

OK, what's the best approach for that? I've updated the readme in the doc 
directory to reflect that, so it'll be present in the source. Can I just 
include the same file in the binary release? The readme file is here:

http://legendofedgar.svn.sourceforge.net/viewvc/legendofedgar/trunk/doc/readme?revision=910&view=markup

Re: Do symbols make sense for C++

2012-01-26 Thread Jérémy Lal 
On 26/01/2012 09:08, Sune Vuorela wrote:
> On 2012-01-26, Russ Allbery  wrote:
>> But that feels like a result contrary to what I had previously thought was
>> the intended direction, so I wanted to ask the Debian development
>> community as a whole: am I missing something?  Are these symbols files
>> actually useful? 
> 
> Symbol files are nice if you have a upstream who doesn't always take
> binary compatibility that serious (which is probably the case for 75% of
> upstreamers). Then you have a list that helps you finding out.
> 
> (and then of course there is the usual bits and pieces about why symbol
> files are useful)
> 
> You do need a bit of knowledge, especially when some of the symbols you
> mentioned go missing (like the std::vector ones), which isn't normally a
> abi break.

About what i wonder (since i'm not c++ expert) if abi-compliance-checker
is serious enough to be used to decide soname bumps ?
http://www.upstream-tracker.org/

Regards,
Jérémy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f210e27.5070...@melix.org

Re: Do symbols make sense for C++

2012-01-26 Thread Reinhard Tartler 
On Do, Jan 26, 2012 at 09:26:15 (CET), Jérémy Lal wrote:

[...]

> About what i wonder (since i'm not c++ expert) if abi-compliance-checker
> is serious enough to be used to decide soname bumps ?
> http://www.upstream-tracker.org/

Thank you very much for pointing out this service. It surely is very
useful for both package maintainers as well as upstreams.


I've analyzed the report for libav:
http://www.upstream-tracker.org/versions/libav.html and found the
results very interesting and enlightning. The results themselves seem
very detailed and accurate to me but I think their interpretations of
the results is too strong. For libav, most of the incompatible changes
are covered by API usage constraints which this automated service cannot
possibly be aware of.  This means that you have to carefully read all of
the report and use the findings with a grain of salt.

Cheers,
Reinhard


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87vcny4z7q@faui43f.informatik.uni-erlangen.de

Re: Do symbols make sense for C++

2012-01-26 Thread Chow Loong Jin 
On 26/01/2012 14:53, Russ Allbery wrote:
> 5. The exported symbols of the library contained many symbols that
>obviously weren't really from that library, but instead were artifacts
>of the C++ compilation process, things like instantiations of
>std::vector.  Do those go into the symbols file?  Do they change from
>architecture to architecture?  If they disappear again, is that
>actually an ABI break?  How do I know?  It's all very mysterious, and
>while shlibs provides the same semantics as just ignoring this, at
>least I'm not then including in the package data, generated by me,
>things that I'm just blindly ignoring.

Most upstream libraries don't usually have any std:: symbols that are meant to
be exported. In the case of libzen and libmediainfo which I recently packaged, I
just added the following to the bottom of my symbols file to ignore them:

 (optional|c++|regex)"^std::" 0.7.52
 (optional|c++|regex)"^(bool|void|MediaInfoLib::File_Mxf::indextable\*) std::"
0.7.52

What I found most frustrating, though, was the size_t handling, which ends up
being expanded into unsigned int on some architectures, and unsigned long on
others, resulting in the same function (which takes a size_t parameter) being
mangled differently per arch. I used the following workaround for size_t using
functions:

 (c++|regex)"MediaInfoLib::MediaInfo::Count_Get\(MediaInfoLib::stream_t,
unsigned (int|long)\)@Base" 0.7.52

And then there's also long double/__float128 (powerpc), which I worked around in
the same manner.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Jérémy Lal  wrote:
> About what i wonder (since i'm not c++ expert) if abi-compliance-checker
> is serious enough to be used to decide soname bumps ?
> http://www.upstream-tracker.org/

The abi checker that iirc is hosted somewhere underneath linuxfoundation
is producing quite good results. I can't find a url for it right now
though. Or the url I found was down for maintenance.

It's a giant perl script with various helper things.


/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji25h8.p7v.nos...@sshway.ssh.pusling.com

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Russ Allbery  wrote:
> I certainly believe there are carefully-maintained C++ libraries that are
> more conservative and that go to the required effort to make this work
> properly, and KDE is probably an excellent example of a large C++ project
> with enough C++ experts involved to do this properly.  But I'm wondering

Ha. it is only libraries from src:kde4libs and src:kdepimlibs that is
properly managed in this regard, and not the only source packages
producing shared libraries consumed by other source packages.


/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji25m3.p7v.nos...@sshway.ssh.pusling.com

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Chow Loong Jin  wrote:
>  (c++|regex)"MediaInfoLib::MediaInfo::Count_Get\(MediaInfoLib::stream_t,
> unsigned (int|long)\)@Base" 0.7.52

(subst)MediaInfoLib::MediaInfo::Count_Get(MediaInfoLib::stream_t
{size_t})@base 0.7.52

note that you might actually want to use the mangled symbol names in
your symbol file, given that all the C0, C1 and C2 contsructors
demangles to the same symbol.

/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji25tb.p7v.nos...@sshway.ssh.pusling.com

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Paul Wise 
On Thu, Jan 26, 2012 at 3:57 PM, Richard Sweeney wrote:

> OK, what's the best approach for that? I've updated the readme in the doc
> directory to reflect that, so it'll be present in the source. Can I just
> include the same file in the binary release? The readme file is here:
>
> http://legendofedgar.svn.sourceforge.net/viewvc/legendofedgar/trunk/doc/readme?revision=910&view=markup

It would be much better if you could release things under a more
friendly license, how about CC-BY-SA? If not, what are your reasons
for that?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6huczf4urzhgtpmf7rshxsnww5a76ukit77x-dyxx8...@mail.gmail.com

Re: Do symbols make sense for C++

2012-01-26 Thread Chow Loong Jin 
On 26/01/2012 17:06, Sune Vuorela wrote:
> On 2012-01-26, Chow Loong Jin  wrote:
>>  (c++|regex)"MediaInfoLib::MediaInfo::Count_Get\(MediaInfoLib::stream_t,
>> unsigned (int|long)\)@Base" 0.7.52
> 
> (subst)MediaInfoLib::MediaInfo::Count_Get(MediaInfoLib::stream_t
> {size_t})@base 0.7.52

That feature has not been implemented, and its bug[1] has been tagged wontfix.

> note that you might actually want to use the mangled symbol names in
> your symbol file, given that all the C0, C1 and C2 contsructors
> demangles to the same symbol.

C0, C1 and C2 constructors? What are those?

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

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Chow Loong Jin  wrote:
>> (subst)MediaInfoLib::MediaInfo::Count_Get(MediaInfoLib::stream_t
>> {size_t})@base 0.7.52
>
> That feature has not been implemented, and its bug[1] has been tagged won=
> tfix.

it's available in pkg-kde-tools as mentioned at other places in this
thread.

> C0, C1 and C2 constructors? What are those?

   ::= C1   # complete object constructor
   ::= C2   # base object constructor
   ::= C3   # complete object allocating constructor
   ::= D0   # deleting destructor
   ::= D1   # complete object destructor
   ::= D2   # base object destructor

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji29ld.p7v.nos...@sshway.ssh.pusling.com

RE: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Paul Wise 
On Thu, 2012-01-26 at 10:00 +, Richard Sweeney wrote:

> The reason for choosing NC is because I don't want someone
> selling something I'm giving away for nothing.
> I take it there's no Debian compatible license
> that allows me to do this?

That would go against items 5 and 6 of the DFSG:

http://www.debian.org/social_contract#guidelines

I find it weird that you would choose the GPL when you do not want
people selling your work. The GPL explicitly allows that.

PS: I'm not sure if you saw this message since it wasn't CCed to you:

http://lists.debian.org/20120125184055.ga19...@angband.pl

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

RE: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Richard Sweeney 
(Apologies if this top posts, sending from my phone)

The reason for choosing NC is because I don't want someone
selling something I'm giving away for nothing.
I take it there's no Debian compatible license
that allows me to do this?

> Date: Thu, 26 Jan 2012 17:28:38 +0800
> Subject: Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game
> From: p...@debian.org
> To: rikswee...@hotmail.com
> CC: debian-devel@lists.debian.org; 653...@bugs.debian.org
> 
> On Thu, Jan 26, 2012 at 3:57 PM, Richard Sweeney wrote:
> 
> > OK, what's the best approach for that? I've updated the readme in the doc
> > directory to reflect that, so it'll be present in the source. Can I just
> > include the same file in the binary release? The readme file is here:
> >
> > http://legendofedgar.svn.sourceforge.net/viewvc/legendofedgar/trunk/doc/readme?revision=910&view=markup
> 
> It would be much better if you could release things under a more
> friendly license, how about CC-BY-SA? If not, what are your reasons
> for that?
> 
> -- 
> bye,
> pabs
> 
> http://wiki.debian.org/PaulWise

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Paul Wise 
On Thu, Jan 26, 2012 at 3:57 PM, Richard Sweeney wrote:

> OK, what's the best approach for that? I've updated the readme in the doc
> directory to reflect that, so it'll be present in the source. Can I just
> include the same file in the binary release? The readme file is here:
>
> http://legendofedgar.svn.sourceforge.net/viewvc/legendofedgar/trunk/doc/readme?revision=910&view=markup

I notice you are using Sourceforge, I think your use of CC-BY-NC-SA is
a violation of their terms of service, so I suggest that you move off
Sourceforge or pick a license that doesn't have that problem.

https://geek.net/terms-of-use

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

RE: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Richard Sweeney 
(Last top post)

After some reading, I can probably just leave the assets under the current 
license. I can simply just change it back since it's currently not released?

> Date: Thu, 26 Jan 2012 18:22:01 +0800
> Subject: Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game
> From: p...@debian.org
> To: rikswee...@hotmail.com
> CC: debian-devel@lists.debian.org; 653...@bugs.debian.org
> 
> On Thu, Jan 26, 2012 at 3:57 PM, Richard Sweeney wrote:
> 
> > OK, what's the best approach for that? I've updated the readme in the doc
> > directory to reflect that, so it'll be present in the source. Can I just
> > include the same file in the binary release? The readme file is here:
> >
> > http://legendofedgar.svn.sourceforge.net/viewvc/legendofedgar/trunk/doc/readme?revision=910&view=markup
> 
> I notice you are using Sourceforge, I think your use of CC-BY-NC-SA is
> a violation of their terms of service, so I suggest that you move off
> Sourceforge or pick a license that doesn't have that problem.
> 
> https://geek.net/terms-of-use
> 
> -- 
> bye,
> pabs
> 
> http://wiki.debian.org/PaulWise

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

2012-01-26 Thread Goswin von Brederlow 
"brian m. carlson"  writes:

> On Wed, Jan 18, 2012 at 03:05:58PM +0100, Goswin von Brederlow wrote:
>> jida...@jidanni.org writes:
>> 
>> > Forty years of pleasant df(1) and mount(1) reading shattered in one day,
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073
>> 
>> Any update on why the root filesystem is listed by UUID? Is that a
>> problem of busybox mount reporting the long device name to the kernel
>> why real mount uses the short one?
>
> It's due to the libata transition.  Since drives that might formerly
> have been hd? are now sd?, there was a debconf question to ask to
> convert them all into UUIDs.  Then it doesn't matter which driver (ide
> or libata or something else entirely) is being used.

That is why there now is an UUID in /etc/fstab. That wasn't the
question.

Anyway, the answere was that busybox mount does not canonicalize the
device name. Only mount from util-linux does.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k44e7m3n.fsf@frosties.localnet

Re: Do symbols make sense for C++

2012-01-26 Thread Florian Weimer 
* Russ Allbery:

> I'm currently working on the Policy modification to document (and
> recommend) use of symbols instead of shlibs, but I'd only personally used
> symbols with C libraries.  Today I decided that I should try adding a
> symbols file to a C++ library, particularly if I'm going to recommend
> everyone do it.  I tried this exercise with xml-security-c, which is, I
> think, a reasonably typical C++ library.

Symbols just don't work for C++.  Large parts of a library ABI are not
expressed in terms of exported symbols.

Let's start with this:

struct Foo {
  long a;
  virtual void foo();
};

Foo *
f()
{
  return new Foo;
}

void
g(Foo *p)
{
  p->foo();
}

It is compiled to:

.globl _Z1gP3Foo
.type   _Z1gP3Foo, @function
_Z1gP3Foo:
.LFB4:
.cfi_startproc
movq(%rdi), %rax
movq(%rax), %rax
jmp *%rax
.cfi_endproc
.LFE4:
.size   _Z1gP3Foo, .-_Z1gP3Foo
.p2align 4,,15
.globl _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$16, %edi
call_Znwm
movq$_ZTV3Foo+16, (%rax)
addq$8, %rsp
ret
.cfi_endproc
.LFE0:
.size   _Z1fv, .-_Z1fv

Now we threw new members to struct Foo and use Foo::bar() in g():

struct Foo {
  long a, b, c;
  virtual void foo();
  virtual void bar();
};

Foo *
f()
{
  return new Foo;
}

void
g(Foo *p)
{
  p->bar();
}

This does not change the symbols at all:

.globl _Z1gP3Foo
.type   _Z1gP3Foo, @function
_Z1gP3Foo:
.LFB4:
.cfi_startproc
movq(%rdi), %rax
movq8(%rax), %rax
jmp *%rax
.cfi_endproc
.LFE4:
.size   _Z1gP3Foo, .-_Z1gP3Foo
.p2align 4,,15
.globl _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$32, %edi
call_Znwm
movq$_ZTV3Foo+16, (%rax)
addq$8, %rsp
ret
.cfi_endproc
.LFE0:
.size   _Z1fv, .-_Z1fv

Two constants change in an incompatible way, but the set of symbols
remains the same.  Of course, this is similar to C code where the size
of structs is not covered by symbol versioning, either.  For the Foo
struct itself, the size dependency can be hidden by only handing out
pointers to application code.  For Foo's vtable (which grows in size
to accommodate the Foo::bar() method), this is more difficult, and
downright impossible if application code needs to derive from Foo and
actually needs the method to be virtual.

In some isolated cases, symbols may still make sense for C++ (e.g., if
the library ABI is really stable and all you need to detect is use of
newly added classes to bump dependencies), but I don't think they work
in general.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762fy3cin@mid.deneb.enyo.de

Re: collab-maint join requests on Alioth

2012-01-26 Thread Enrico Zini 
On Tue, Jan 24, 2012 at 07:57:10AM +0100, Raphael Hertzog wrote:

> I don't know if this has been fixed on the FusionForge side, but when I
> was processing collab-maint, this was not the case. Alioth did not send
> out such mails (i.e. when you accepted/declined a join request).
> 
> If that's still the case, you might want to ask the sponsor to CC his
> mail to the person requesting access so that you can group reply and
> inform that the request has been processed.

Good point, I really assumed that alioth would send you a notification
mail.

We can try to manually inform people when we accept them, but me being
one of those that would have to spend time doing it, I would consider
that to be a useless extra burden, as is the case with everything that
could easily be automated.

Can we have GForge send a notification mail on approval/decline, at
least for collab-maint?


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread Martin Bagge / brother 
On 2012-01-26 11:51, Richard Sweeney wrote:
> After some reading, I can probably just leave the assets under the current 
> license. I can simply just change it back since it's currently not released?

If "current" license is GPL and someone make a fork based on that your
license change in the future will not have an impact on the fork.
A "release" has no value when regarding what license the work is
available as.

There are several articles about the problem with CC NC licenses,
exactly what that means is not clear. Make sure to study the field
before picking anything based on NC.
Pick license and pick it wise.
-- 
brother
http://sis.bthstudent.se


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

Re: collab-maint join requests on Alioth

2012-01-26 Thread Raphael Hertzog 

On Thu, 26 Jan 2012, Enrico Zini wrote:
> Good point, I really assumed that alioth would send you a notification
> mail.
> 
> We can try to manually inform people when we accept them, but me being
> one of those that would have to spend time doing it, I would consider
> that to be a useless extra burden, as is the case with everything that
> could easily be automated.
> 
> Can we have GForge send a notification mail on approval/decline, at
> least for collab-maint?

FWIW, I opened
https://alioth.debian.org/tracker/?func=detail&group_id=1&aid=304644&atid=21
in 2007.

I think you'll have to find a way to bribe Roland or another FusionForge
hacker... :-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120126132015.gc21...@rivendell.home.ouaza.com

Re: RFC: Realtime system (audio) group

2012-01-26 Thread Josselin Mouette 
Le mercredi 25 janvier 2012 à 13:31 +0100, Adrian Knoth a écrit : 
> > If you have PolicyKit, rtkit defaults to letting you have rt priorities
> > if and only if you are logged in locally (gdm, kdm, getty etc., but not
> 
> Is there something like
> 
> "If you're logged in locally, I'll grant you RT prios"?
> 
> that does not require the application to use dbus? So to say, "@local"
> PAM magic or inherited from gdm/kdm/getty?

Currently two things are supported by ConsoleKit/PolicyKit: D-Bus
interfaces, and device permissions (udev sets dynamic ACLs on some
devices when you are on the console). If you need things like Unix
sockets, currently there is no code to support them (but there is no
technical limitation).

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: collab-maint join requests on Alioth

2012-01-26 Thread Enrico Zini 
On Thu, Jan 26, 2012 at 02:20:15PM +0100, Raphael Hertzog wrote:

> > Can we have GForge send a notification mail on approval/decline, at
> > least for collab-maint?
> 
> FWIW, I opened
> https://alioth.debian.org/tracker/?func=detail&group_id=1&aid=304644&atid=21
> in 2007.
> 
> I think you'll have to find a way to bribe Roland or another FusionForge
> hacker... :-)

Excellent! I'll just blame Roland and the FusionForge people, pointing
at that link, every time someone will get upset at me because I forgot
to notify them :)


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: Do symbols make sense for C++

2012-01-26 Thread Lisandro Damián Nicanor Pérez Meyer 
On Jue 26 Ene 2012 05:08:07 Sune Vuorela escribió:
[snip]
> >Am I missing some trick to make them useful?
> 
> You miss pkgkde-symbolshelper written by the fabulous Modestas Vainius
> which is available in pkg-kde-tools.
> 
> http://pkg-kde.alioth.debian.org/symbolfiles.html

+1. As Sune said in other mail, only :kde4libs and src:kdepimlibs are normally 
properly managed. But there are lots of third-party libs we have to maintain 
and pkg-kde-tools have been very helpfull in this regard.

Kinds regards, Lisandro.

-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

A package question

2012-01-26 Thread Svante Signell 
Hi,

I need to install an old package, having a dependency on
libreadline5-dev. This -dev package does no longer exist, it is replaced
by libreadline-gplv2-dev. From the package description that package
conflicts with libreadline5-dev, and replaces libreadline5-dev. Still
the old package refuses to install.

Shouldn't libreadline-gpl2-dev also have a Provides: libreadline5-dev
entry? In case not, how to enable the installation of that old package.

Depends: libreadline5 (= 5.2-11), libtinfo-dev, dpkg (>= 1.15.4) |
install-info
Conflicts: libreadline-dev, libreadline5-dev
Replaces: libreadline5-dev

Maybe this is a debian-user question, but I think it is not.
Thanks!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1327592058.12680.676.ca...@s1499.it.kth.se

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

2012-01-26 Thread The Fungi 
On 2012-01-26 13:06:31 +0100 (+0100), Martin Bagge / brother wrote:
[...]
> There are several articles about the problem with CC NC licenses,
> exactly what that means is not clear. Make sure to study the field
> before picking anything based on NC.
> Pick license and pick it wise.

The historic quagmire with DikuMUD's license (and subsequent
inability of derivative software authors to be able to round up all
the original copyright holders for later relicensing) is a great
example:

http://en.wikipedia.org/wiki/DikuMUD#DikuMUD_license

The project was widely used and a fertile developer community
emerged around it back in the shareware days before proliferation of
more modern Free/Libre OSS licenses. Unfortunately, now, a vast
majority of the MUDsphere inherits that noncommercial license and is
thus legally incompatable with most current free software projects.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


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

[Fwd: A package question]

2012-01-26 Thread Svante Signell 
Sorry, I just realized I'm not subscribed to debian-deval from the
mailing address below.

 Forwarded Message 
From: Svante Signell 
Reply-to: 
To: debian-devel 
Subject: A package question
Date: Thu, 26 Jan 2012 16:34:18 +0100

Hi,

I need to install an old package, having a dependency on
libreadline5-dev. This -dev package does no longer exist, it is replaced
by libreadline-gplv2-dev. From the package description that package
conflicts with libreadline5-dev, and replaces libreadline5-dev. Still
the old package refuses to install.

Shouldn't libreadline-gpl2-dev also have a Provides: libreadline5-dev
entry? In case not, how to enable the installation of that old package.

Depends: libreadline5 (= 5.2-11), libtinfo-dev, dpkg (>= 1.15.4) |
install-info
Conflicts: libreadline-dev, libreadline5-dev
Replaces: libreadline5-dev

Maybe this is a debian-user question, but I think it is not.
Thanks!





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1327596049.12680.678.ca...@s1499.it.kth.se

Re: Do symbols make sense for C++

2012-01-26 Thread Bernhard R. Link 
* From: Russ Allbery, Wed, 25 Jan 2012 22:53:04 -0800
> 4. Once I had a symbols file that resulted in a successful build and
> that I could have uploaded, I started thinking about how I was going
> to maintain it. With a C program, I would change the symbols file
> versions when the underlying function implementation changes in a way
> that may not offer eqiuvalence, similar to bumping shlibs. I realized
> that I was going to have no idea when that happened, and the only way
> that I would maintain the symbols file would be to either trust
> upstream to maintain ABI equivalence and therefore only change the
> symbols file when upstream changes the SONAME, or not trust upstream
> to maintain ABI equivalence and therefore change all the versions with
> each new upstream release.  That gives me exactly the same semantics
> as a shlibs file, so what's the point in having a symbols file?

How many upstream are there that try to achieve ABI equivalence?
Usually people only try to achieve ABI compability, i.e. programs
compiled against the old version will work with the new one, but
there is no garantee that programs compiled against the new version
also work with the new one.
(And in that case the maintainer has to manually increase the versions
in the symbols file, just as they needed to increment the shlibs file
before (unless they used auto-updating by using dh_makeshlibs -V without
any version anyway)).

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120126161155.ga22...@server.brlink.eu

Re: Do symbols make sense for C++

2012-01-26 Thread Russ Allbery 
"Bernhard R. Link"  writes:

> How many upstream are there that try to achieve ABI equivalence?
> Usually people only try to achieve ABI compability, i.e. programs
> compiled against the old version will work with the new one, but there
> is no garantee that programs compiled against the new version also work
> with the new one.

I'm not sure.  I'm not even sure that the libraries I'm looking at really
do try to do this, although that's the impression that I've gotten.
Usually a bug-fix-only policy will do this (although not necessarily).

> (And in that case the maintainer has to manually increase the versions
> in the symbols file, just as they needed to increment the shlibs file
> before (unless they used auto-updating by using dh_makeshlibs -V without
> any version anyway)).

Right, that's the conclusion I reached.  And it's easier to do that with
shlibs than symbols.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkdagw8s@windlord.stanford.edu

Re: Do symbols make sense for C++

2012-01-26 Thread Thomas Weber 
On Thu, Jan 26, 2012 at 08:08:07AM +, Sune Vuorela wrote:
> >Am I missing some trick to make them useful?
> 
> You miss pkgkde-symbolshelper written by the fabulous Modestas Vainius
> which is available in pkg-kde-tools.
> 
> http://pkg-kde.alioth.debian.org/symbolfiles.html

I'm currently creating symbol files for Octave in Debian. And quite
frankly, the way symbol files for C++ libraries are handled and
(especially) documented is totally frustrating.

There's exactly zero precise documentation on how to maintain symbol
files there. When the topic is brought up on mailing list, people point
at some tools from the KDE packages, but still there's no documentation
on the problem itself. The best example is dpkg-gensymbols(1) itself:

[topic is the 'optional' tag]:
"For example, most of C++ template instantiations fall into this category".

Yeah, great. Which instantiations cannot be marked as optional and how
do I recognize them? And if it's actually impossible to maintain symbol
files for C++ libraries (as Florian Weimer has claimed in this thread),
why doesn't the manpage just say so?

Thomas


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

Re: Do symbols make sense for C++

2012-01-26 Thread Sune Vuorela 
On 2012-01-26, Thomas Weber  wrote:
> I'm currently creating symbol files for Octave in Debian. And quite
> frankly, the way symbol files for C++ libraries are handled and
> (especially) documented is totally frustrating.
>
> There's exactly zero precise documentation on how to maintain symbol
> files there. When the topic is brought up on mailing list, people point
> at some tools from the KDE packages, but still there's no documentation
> on the problem itself. The best example is dpkg-gensymbols(1) itself:

did you read the link I posted? That's currently the best docs we have
for pkgkde-symbolshelper. Better docs is always a nice thing to have.
Please help improve it.

> Yeah, great. Which instantiations cannot be marked as optional and how
> do I recognize them? And if it's actually impossible to maintain symbol
> files for C++ libraries (as Florian Weimer has claimed in this thread),
> why doesn't the manpage just say so?

It is not at all impossible to maintain symbol files for c++ libraries.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnji3pji.p7v.nos...@sshway.ssh.pusling.com

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

2012-01-26 Thread Antonio Terceiro 
Jakub Wilk escreveu isso aí:
> * Antonio Terceiro , 2012-01-25, 10:12:
> >Another argument in favor of using the same name for source and
> >binary packages: suppose there is "libfoo", and independent
> >bindings for Perl, Python and Ruby, all called "foo", and that
> >"foo" is unique in their respective upstream language-specific
> >namespaces (CPAN/PyPi/Rubygems); which one gets to use the 'foo'
> >source package name in Debian?
> 
> None of them, of course.
> 
> This is an argument for naming source packages in a sane way when
> your upstream for some reasons could do that himself... Not much to
> do with $binarypackagename==$sourcepackagename, really.

What's sane for us is not what's sane for upstream. Having a unique
name in PyPi is perfectly sane for Python developers, and they won't
check every other language archive to make sure their package name
doesn't clash with any other package in any other language.

Debian, on the other hand, requires a globally unique name.  Acting
consistently and sticking to the per-language standards for naming
packages, including source packages, is the Debian solution for
guaranteeing a unique name.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Work-needing packages report for Jan 27, 2012

2012-01-26 Thread wnpp 
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 397 (new: 5)
Total number of packages offered up for adoption: 151 (new: 3)
Total number of packages requested help for: 59 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   arrayprobe (#656590), orphaned 6 days ago
 Description: command line HP (Compaq) SmartArray status checker
 Installations reported by Popcon: 248

   cpqarrayd (#656592), orphaned 6 days ago
 Description: monitoring tool for HP (Compaq) SmartArray controllers
 Installations reported by Popcon: 276

   envstore (#657333), orphaned yesterday
 Installations reported by Popcon: 24

   fossology (#656591), orphaned 6 days ago
 Description: open and modular architecture for analyzing software
 Reverse Depends: fossology fossology-agents fossology-agents-single
   fossology-scheduler fossology-scheduler-single fossology-web
   fossology-web-single
 Installations reported by Popcon: 10

   xclip (#657329), orphaned yesterday
 Reverse Depends: slimrat
 Installations reported by Popcon: 2009

392 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   aspic (#657083), offered 3 days ago
 Description: Line art generator
 Installations reported by Popcon: 27

   barry (#657076), offered 3 days ago
 Reverse Depends: barry-util barry-util-dbg barrybackup-gui
   barrybackup-gui-dbg libbarry-dev libbarry0-dbg
 Installations reported by Popcon: 108

   movabletype-opensource (#657240), offered 2 days ago
 Description: A well-known blogging engine
 Installations reported by Popcon: 38

148 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] movabletype-opensource (#657240), requested 2 days ago
 Description: A well-known blogging engine
 Installations reported by Popcon: 38

   apache2 (#646208), requested 96 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (178 more
   omitted)
 Installations reported by Popcon: 60843

   apt-xapian-index (#567955), requested 724 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 50483

   asymptote (#517342), requested 1063 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 2987

   athcool (#278442), requested 2648 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 95

   balsa (#642906), requested 123 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg debreaper
 Installations reported by Popcon: 270

   bastille (#592137), requested 537 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 254

   boinc (#511243), requested 1113 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1861

   cardstories (#624100), requested 276 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   chromium-browser (#583826), requested 606 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 9701

   cryptsetup (#600777), requested 463 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7341

   cvs (#354176), requested 2163 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more