Re: SUMMARY: Re: shared library -dev package naming proposal
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: >> fact 3: libtool library libtool tries to implement a wrapper >> around shared library and static library, so that both of them >> can be uniformly processed, and allows specifying just: libtool >> cc -lnewt a.c Steve> Why is this better? Because it means your application you are linking does not need to know the implementation details behind libnewt, or what libraries this particular version of libnewt happens to require. This might not be a sane example, but consider if the maintainer of libnewt suddenly recompiled new versions of the package to depend on libssl for example, this might result in all applications that use libnewt statically unable to build, because the list of libraries is hard coded. This example is simple, for a more complicated example, see the Heimdal libraries... This may be important if you require a static version for any reason or your platform doesn't support interdependencies between shared libraries. I think there is at least one OS without good support for shared libraries - what was its name again? - not very common - I think its called "MS-Windows". -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unsubscribe
Benita Hsueh/Toronto/IBM is out of Office
I will be out of the office starting 07/29/2005 and will not return until 09/01/2005. I will have limited connectivity. If you need immediate assistance, please contact Melody Ng. Benita. For NextWave Issues or questions, please contact Paul Rodriguez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Goswin von Brederlow:
>
>>> This was once desirable because you couldn't declare real constants in
>>> classes. Today,
>>>
>>> template
>>> struct Foo
>>> {
>>> static const unsigned N = T::N;
>>> char bar[N];
>>> };
>>>
>>> works and the enum trick lost its importance.
>>
>> Doesn't that still make N a real variable in memory and does not get
>> optimized away like enums?
>
> Only if you provide a definition, and not just a declaration, it
> seems.
The proper use of this construct seems to be:
template
struct Foo {
static const unsigned N = T::N;
char bar[N];
};
struct Bla {
static const unsigned N;
};
const unsigned Bla::N = 10;
int main() {
Foo foo;
}
Correct me if I'm wrong but doesn't that
1.) Only move the const declaration from the template into the
template parameter?
2.) Cause the template to have static member N in every file that uses
the template and for every type?
3.) Cause Bla to have a static member N in every file that uses
the template and for every type?
4.) Cause 2 extra indirections due to 2+3?
By the way,
template
struct Foo {
static const unsigned N = 10;
char bar[N];
};
works just as well.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320503: ITP: camlgz -- Ocaml zlib and bzip2 library bindings
Package: wnpp Severity: wishlist Owner: Thomas Petazzoni <[EMAIL PROTECTED]> * Package name: camlgz Version : 0.5.6 Upstream Author : Olivier Andrieu <[EMAIL PROTECTED]> * URL : http://ocamlplot.sourceforge.net/#gz * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Ocaml zlib and bzip2 library bindings Ocaml bindings for the zlib and bzip2 libraries. It allows transparent reading and writing of compressed files from Ocaml. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.11 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On Fri, 29 Jul 2005, Florian Weimer wrote: > * Jaakko Niemi: > > > So, if I'm understanding this and the discussion > > that followed correctly, we should change the > > enum to constants. > > Eh, no, sorry. This will almost certainly break things because this > is a C header, not C++. Sorry, just #defines instead of enum is what I meant. Just had some rather strong cough medicine.. Now, to #define a const.. mmm, cheese.. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which CD is a package on?
fenio wrote: >On Fri, Jul 29, 2005 at 02:25:41PM +0200, Jerome Warnier wrote: >> I wonder if it is possible to find out on which CD of a stable release >> the package I look for is? >> I guess it is possible, as apt can do it. >> But is it available somewhere online? > >Right now it's possible only by looking jigdo files.=20 > >Online browser/search engine is on my TODO list :/ I'm going to look into automatically producing list files as part of the CD build process... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which CD is a package on?
On Fri, Jul 29, 2005 at 07:38:30PM -0300, Guilherme de S. Pastore wrote: > Sorry, it doesn't work. Just replace the name of the service with the > real name of the machine currently hosting it. [...] Sorry I was first with previous mail ;) regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Which CD is a package on?
On Fri, Jul 29, 2005 at 07:33:10PM -0300, Guilherme de S. Pastore wrote: > The (ugly) script that generated it is on > http://alioth.debian.org/~ftlerror-guest/cdpkglist.sh. ([EMAIL PROTECTED])~$wget http://alioth.debian.org/~ftlerror-guest/cdpkglist.sh --00:39:29-- http://alioth.debian.org/~ftlerror-guest/cdpkglist.sh => `cdpkglist.sh' Resolving alioth.debian.org... 192.25.206.28 Connecting to alioth.debian.org|192.25.206.28|:80... connected. HTTP request sent, awaiting response... 404 Not Found 00:39:30 ERROR 404: Not Found. ([EMAIL PROTECTED])~$ regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Which CD is a package on?
Em Sex, 2005-07-29 às 19:33 -0300, Guilherme de S. Pastore escreveu: > http://alioth.debian.org/~ftlerror-guest/list.txt > http://alioth.debian.org/~ftlerror-guest/cdpkglist.sh. Sorry, it doesn't work. Just replace the name of the service with the real name of the machine currently hosting it. http://haydn.debian.org/~ftlerror-guest/list.txt http://haydn.debian.org/~ftlerror-guest/cdpkglist.sh -- Guilherme de S. Pastore (fatalerror) <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320492: ITP: dhcp-helper -- A DHCP relay agent.
Package: wnpp Severity: wishlist * Package name: dhcp-helper Version : 0.2 Upstream Author : Simon Kelley <[EMAIL PROTECTED]> * URL : http://www.thekelleys.org.uk/dhcp-helper * License : GPL Description : A DHCP relay agent. Dhcp-helper is a DHCP and BOOTP relay agent. It listens for DHCP and BOOTP broadcasts on directly connected subnets and relays them to DHCP or BOOTP servers elsewhere. It also relays replies from the remote servers back to partially configured hosts. Dhcp-helper requires a 2.2 or later Linux kernel. The "packet socket" facility must be available, either compiled into the kernel or as a module. The "Linux packet filter" is not required, which is the chief advantage of this software over the ISC DHCP relay daemon. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which CD is a package on?
Em Sex, 2005-07-29 às 14:25 +0200, Jerome Warnier escreveu: > But is it available somewhere online? There is a list of packages in each CD automatically generated from jigdo files on http://alioth.debian.org/~ftlerror-guest/list.txt, where list.txt is a symlink to list_.txt, currently list_3.1_r0a.txt. The (ugly) script that generated it is on http://alioth.debian.org/~ftlerror-guest/cdpkglist.sh. It's not exactly what you're looking for, but I thought it might be of help. I might look into writing some look up/search thing soon, too. Regards, -- Guilherme de S. Pastore (fatalerror) <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Which CD is a package on?
On Fri, Jul 29, 2005 at 02:25:41PM +0200, Jerome Warnier wrote: > I wonder if it is possible to find out on which CD of a stable release > the package I look for is? > > I guess it is possible, as apt can do it. > But is it available somewhere online? Right now it's possible only by looking jigdo files. Online browser/search engine is on my TODO list :/ regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: RFC, problem with g++4
* Jaakko Niemi: > So, if I'm understanding this and the discussion > that followed correctly, we should change the > enum to constants. Eh, no, sorry. This will almost certainly break things because this is a C header, not C++. Just use #defines, as suggested by Brian M. Carlson in <[EMAIL PROTECTED]>. But I'd also ask upstream first. Maybe they have a strong opinion about this matter, and it's probably not a good idea to diverge needlessly because it might impact cross-distribution portability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
Hello, > Someone suggested an announcement should be sent to > > d-d-a. What do you think ? > > Yes, go to it and find some reviewer. Will do... > Maybe you should add a 'get a random Description' link on your Page... I'm not sure it would be very good, because it's better to review related packages together. It's however true that it could probably make the whole stuff more attractive. > and you should add some 'send the new description to the BTS' > > After the two reviewer write a new/better/improved/... description, > the new description should be send to the BTS as minor bug. Yes. Actually (I now detailed this on the wiki page), what I tought could be done is to make available a public patch repository and announce it soundly. What we can hope is that maintainers will use these patches, making a bug report useless. Of course, after a few weeks, we would file bugs. Regards, -- Clément -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On Fri, 29 Jul 2005, Florian Weimer wrote:
> This was once desirable because you couldn't declare real constants in
> classes. Today,
>
> template
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
So, if I'm understanding this and the discussion
that followed correctly, we should change the
enum to constants. Unless anyone objects, I'll
file a bug against libc6-dev tomorrow asking for
it.
--j
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On 20050729T17+0200, Florian Weimer wrote: > > The problem is, your trick doesn't work outside templates, > > Huh? [After testing it:] I'll be damned. I was sure I was right :) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Public service announcement about Policy 10.4
On Fri, Jul 29, 2005 at 01:16:36PM +0200, Thomas Hood wrote: > Brian M. Carlson wrote: > > I would like to point out that the following are not POSIX features: > > local > > test -o > > test -a > Regarding "local", see #294962. I would like to see support for > "local" added to posh and "local" added as an exception to the > "POSIX-only" rule laid down in 10.4. Well, please note that posh is not the only shell that lacks support for local. IIRC, it also breaks down under one or more of dash and busybox sh. > See #267142 for a long discussion of the "POSIX-only" rule. > I support the idea of requiring #!/bin/sh scripts to be runnable on > posh. I don't. One might as well be able to expand "posh" as the "Pathologically Overstrict SHell"; while Policy's mandate of POSIX sh is important as a standard, the practical impact is nil once you start questioning those POSIX extensions that are supported by all of bash, ksh, dash, and busybox. There are many bugs of much greater practical importance that people could be working on instead. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RFC, problem with g++4
* Olaf van der Spek: >> Only if the compiler knows all uses of that constant. With dynamic >> linking, you can't know that very easily. > > I thought you meant optimizing code that accesses it for performance. > I don't think the space optimization is important. The space optimization is crucial for some template code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On 7/29/05, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: > On 20050729T16+0200, Olaf van der Spek wrote: > > On 7/29/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > Florian Weimer <[EMAIL PROTECTED]> writes: > > > Doesn't that still make N a real variable in memory and does not get > > > optimized away like enums? > > > > I think it's (only) required to have an address. > > I don't see why the compiler can't optimize it away (if it's const). > > Only if the compiler knows all uses of that constant. With dynamic > linking, you can't know that very easily. I thought you meant optimizing code that accesses it for performance. I don't think the space optimization is important.
Re: RFC, problem with g++4
* Thiemo Seufer: >> With dynamic linking, you can't know that very easily. > > The compiler knows nothing about dynamic linking, since this is outside > the compilation unit. Indeed, and the fact that you can use such a constant as a template argument just stresses that it's a compile-time thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote: > This is nice, but I think it's not really very autoconfish [tm] in > spirit. It is not meant to be autoconfish. It is meant to be run _before_ configure, so you can decide if you have to re-libtoolize the package or not. > Also, this invokes autoconf, > which we don't necessarily want to do at package build time since this > will cause packages to require a build dependency on autotools, a > topic which has been discussed at length before. I think I know what you miss: you think about checking the version of the _installed_ libtool package. But that is completely uninteresting as it will _not_ be used during the build. You want to know the libtool version that was used for _generating_ the source package (or upstream tarball). And if that version is wrong, then you have to re-run libtoolize and autoconf anyway, so you do need to have autotools installed. If you do not want to build-depend on autotools then it is too late to check the libtool version at build time (well, you can still check it and generate an explicit FTBFS if it is wrong so forgetting to re-libtoolize the package will be detected more easily). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
> grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh | cut -d= -f2
This is nice, but I think it's not really very autoconfish [tm] in
spirit. Perhaps it would be better to be able to detect whether the
desired feature (whatever that is) is present in the appropriate
libtool rather than looking at the version number. I had indicated in
an earlier post that maybe looking at .la files would be possible,
though this is by no means a certainty. Also, this invokes autoconf,
which we don't necessarily want to do at package build time since this
will cause packages to require a build dependency on autotools, a
topic which has been discussed at length before. If we went the route
of detecting libtool version, I believe we would need to know the
version of libtool that was used to create the .la file of the
dependent package. Is this right? Maybe not -- I'm not fully up to
speed on all the issues yet. Anyway, I'll put together a more
comprehensive proposal on how dh_libtool should work when I have a
chance to work on it. (Unfortunately, that's not going to be for a
few weeks -- things are even more unusually busy than their usual
level of unusualness right now in both my personal and professional
lives...) Of course, all ideas and suggestions such as this are
welcome and are being saved in my notes, in spite of any first
impressions I may have on whether they will actually work
specifically. Thanks. :-)
--
Jay Berkenbilt <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
Antti-Juhani Kaijanaho wrote: > On 20050729T16+0200, Olaf van der Spek wrote: > > On 7/29/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > Florian Weimer <[EMAIL PROTECTED]> writes: > > > Doesn't that still make N a real variable in memory and does not get > > > optimized away like enums? > > > > I think it's (only) required to have an address. > > I don't see why the compiler can't optimize it away (if it's const). > > Only if the compiler knows all uses of that constant. The declared use is enough. > With dynamic linking, you can't know that very easily. The compiler knows nothing about dynamic linking, since this is outside the compilation unit. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
* Antti-Juhani Kaijanaho: > That is not a new trick, I'm fairly sure that was legal when I first > learned of the enum idiom. It's illegal according to The C++ Programming Language, Second Edition (which was published in 1991). I didn't claim the trick was new. 8-) > The problem is, your trick doesn't work outside templates, Huh? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On 20050729T151821+0200, Florian Weimer wrote:
> Today,
>
> template
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
That is not a new trick, I'm fairly sure that was legal when I first
learned of the enum idiom. The problem is, your trick doesn't work
outside templates,
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
signature.asc
Description: Digital signature
Re: RFC, problem with g++4
* Goswin von Brederlow:
>> This was once desirable because you couldn't declare real constants in
>> classes. Today,
>>
>> template
>> struct Foo
>> {
>> static const unsigned N = T::N;
>> char bar[N];
>> };
>>
>> works and the enum trick lost its importance.
>
> Doesn't that still make N a real variable in memory and does not get
> optimized away like enums?
Only if you provide a definition, and not just a declaration, it
seems.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On 20050729T16+0200, Olaf van der Spek wrote: > On 7/29/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > Florian Weimer <[EMAIL PROTECTED]> writes: > > Doesn't that still make N a real variable in memory and does not get > > optimized away like enums? > > I think it's (only) required to have an address. > I don't see why the compiler can't optimize it away (if it's const). Only if the compiler knows all uses of that constant. With dynamic linking, you can't know that very easily. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: RFC, problem with g++4
On 7/29/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Florian Weimer <[EMAIL PROTECTED]> writes: > Doesn't that still make N a real variable in memory and does not get > optimized away like enums? I think it's (only) required to have an address. I don't see why the compiler can't optimize it away (if it's const).
Re: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
> I'd think we could come up with a way to detect the version of libtool
> in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh | cut -d= -f2
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Antti-Juhani Kaijanaho:
>
>> The anon enumeration trick has been an established C++ idom for years
>> (ISTR, but cannot check now, even Stroustrup himself advocating it).
>
> This was once desirable because you couldn't declare real constants in
> classes. Today,
>
> template
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
Doesn't that still make N a real variable in memory and does not get
optimized away like enums?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote: > We've had that discussion before. Last I recall there wasn't really a > huge fight to keep them. Well, Debian developers do not really need them. But there are people who do not develop Debian but develop other software _using_ Debian and static linking is important for them (for example, if you have to submit a job to a remote machine where you have no knowledge nor control over what software is installed, you have no other choice than to link everything (except maybe libc) statically into your application). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Another gnutls ABI change / (small) mass bug filing
Hi,
gnutls changed their ABI again.
Due to historical reasons (the API changes in the past were somewhat
intrusive), the -dev package of libgnutls had been named
libgnutls{,10,11}-dev. The API is now sufficiently stable that this
naming scheme does not make sense any more.
Therefore, in the last upload (of gnutls12) I have renamed the -dev
package, yet again (but for the last time), back to libgnutls-dev. (I
thought about not touching the name; it'd work, but that would be just
*ugly*, not to mention confusing.)
You should know if your package uses this library ;-) so please update it.
I'll file a heap of bugs for the rest, in a week or so.
The following packages are affected:
bitlbee camorama centericq cherokee crywrap cupsys dcgui echoping
elinks exim4 gabber2 gaim ggz-kde-client ggz-utils gjiten gkrellm
gnome-vfs2 gnotime lftp libggz libgnetwork libiksemel libsoup
libsoup2.0 lock-keys-applet loudmouth lynx lynx-cur mailutils
mutt nufw openldap2 pnet-assemblies slrn snowdrop thy vlc weechat
wmbiff wzdftpd xmlsec1
Gnutls in Debian is properly versioned (as opposed to Upstream, which
dropped the versioning script for no good reason), and thus I am
confident that there will not be any library conflicts during this
transition.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Giving every man a vote has no more made men wise
and free than Christianity has made them good.
-- H.L. Mencken
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: shared library -dev package naming proposal
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote: > Why is this better? I have to change my perfectly normal, standard Unix > link command to use something that completely hides the actual link > command and makes debugging problems nearly impossible? Exercise: let's say I have an application that uses GSSAPI, and has to be able to be built statically. Requirements: - It should build with Heimdal's libgssapi - It should build with MIT's libgssapi - It should build with Globus GSI All these cases require a completely different set of dependant static libraries even though I'm only using the GSSAPI interface. With libtool, it's trivial, since all the information you need is already expressed in the .la files. Care to explain a method that is - better than libtool - works already (the most important requirement being that Globus must support it out-of-the-box) - not Debian-specific (only a minor set of the target machines runs Debian)? > I really don't get it. And, for the record, the company I work for > ships code for a variety of Unices. I spend a *lot* more of my time > debugging libtool brokenness (not to mention auto* brokeness) than I > do tracking down which libraries need which other libraries. So when I > say "I don't get it", it's not lack of experience with the tools, I'm > just completely mystified why people think that libtool is an > *improvement*. Well, I have used libtool on a couple of architectures and my opinion is that using libtool is still way more effective than re-inventing it over and over again. Yes, it has bugs (for example the AIX support is notoriously buggy), but they can be fixed just like any other software. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
* Antti-Juhani Kaijanaho:
> The anon enumeration trick has been an established C++ idom for years
> (ISTR, but cannot check now, even Stroustrup himself advocating it).
This was once desirable because you couldn't declare real constants in
classes. Today,
template
struct Foo
{
static const unsigned N = T::N;
char bar[N];
};
works and the enum trick lost its importance.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please participate in popularity-contest
On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: > Nothing garanties that cron jobs are run at the right time. Running > it a bit later (whenever you boot) is just like it being delayed due > to excess load. If there are things that shouldn't be run at the wrong > time we should find them and protect them in the job itself. Running a job a little later is not a problem. Running a job during work hours when it was scheduled to run during the night _is_ a problem since such jobs can (and usually do) hog both memory and I/O bandwidth, making interactive work difficult. In such cases not running the job for a day or two is way better than running it at a time it was not meant to run; not because it causes damage but because it causes real user inconvenience. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages descriptions review
On Fri, Jul 29, 2005 at 08:23:26AM +0200, Clément Stenac wrote: > > If you go to review all description, please check the technical parts > > also. > > Sure, thanks for the reminder. I added it to the wiki page Thanks > I think the interface is now ready for the work to begin. However, very > few people replied. Someone suggested an announcement should be sent to > d-d-a. What do you think ? Yes, go to it and find some reviewer. > Anyway, it is possible to start the work with the interested persons > now... > I set up a table on the wiki page > ( http://wiki.debian.net/?PackagesDescriptionsReview ). > > Please register yourself on this page before starting work on a section. Maybe you should add a 'get a random Description' link on your Page... > I think we should begin by the desktop packages (x11, gnome, kde, ...). > I don't think base packages should be given a high priority as people > don't often want to install them. Libs and devel packages are also lower > priority IMHO and you should add some 'send the new description to the BTS' After the two reviewer write a new/better/improved/... description, the new description should be send to the BTS as minor bug. Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debsupport.de PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Du wei?t doch... jeder hat die Software, die er verdient hat. --- Felix von Leitner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Which CD is a package on?
I wonder if it is possible to find out on which CD of a stable release the package I look for is? I guess it is possible, as apt can do it. But is it available somewhere online? Thanks -- Jerome Warnier <[EMAIL PROTECTED]> BeezNest -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Work-needing packages report for Jul 29, 2005
* Florian Weimer <[EMAIL PROTECTED]> [2005-07-29 12:32]: > > ml-nlffigen ml-lex libckit-smlnj ml-yacc ml-burg libcmlutil-smlnj > > libpgraphutil-smlnj smlnj nowhere libmlrisctools-smlnj libcml-smlnj > > > >standard (#319801), offered 4 days ago > > This looks like some script bug. Fixed, thanks. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes: > On 20050729T083332+, Brian M. Carlson wrote: >> Of course, I could be persuaded that the enumeration is a good idea, but >> I don't see what problem it solves, and it only seems to cause them. > > The anon enumeration trick has been an established C++ idom for years > (ISTR, but cannot check now, even Stroustrup himself advocating it). > It's a shame if it now suddenly stopped working and is somehow against > the standard, even. > > The problem with #defines is that they're outside the language proper > and, for example, pay no attention to namespaces. > -- > Antti-Juhani Kaijanaho, Debian developer > > http://kaijanaho.info/antti-juhani/blog/en/debian But that is C code and the defines are there anyway, but currently they are save NOPs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312897: ITP: texlive -- The TeXlive system packaged for debian
Dear Developers! I have a question concerning the .orig.tar.gz files for the following ITP: On Fre, 10 Jun 2005, Norbert Preining wrote: > Package: wnpp > Severity: wishlist > Owner: Norbert Preining <[EMAIL PROTECTED]> > > * Package name: texlive > Version : 2005.1 > Upstream Author : TeXlive Mailing List <[EMAIL PROTECTED]> > * URL : http://www.tug.org/texlive > * License : mixed, but all Debian conform > Description : The TeXlive system packaged for debian > > TeX Live is an easy way to get up and running with TeX. It includes all > major freely-available TeX-related programs, macro packages, and fonts, > including support for many languages around the world. TeX live has a very peculiar distribution model: There is a Perforce depot and the CD/DVDs. This is upstream. I have prepared around 80 binary .debs with the binaries included in TeX live (see http://www.tug.org/texlive/debian.html). Now I am going to make proper debian packages. Herein the following problems occur: One option would be to make one (1!) .orig.tar.gz from the whole TeXLive depot stuff necessary, this would amount to an orig.tar.gz of 456 M and from this .orig.tar.gz build all the 80 packages. Would this be a feasable option, or would I get killed immediately when doing this? Another option would be to separate the arch-independent packages out, create for each of them a separate .orig.tar.gz containing the necessary subset of the TeX live tree, and one (smaller, but still big) .orig.tar.gz for the arch-dependend packages together with the necessary files. Finally, I could go for the complete split, which would produce a set of .orig.tar.gz which are the respective subsets of the TeX live depot, but these would not resemble `upstream' as is. Please enlighten me on this matter. Best wishes Norbert PS: If someone has the urge to mentor me for upload (it is still a long way, but I have to plan ahead) please contact me. --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- BOOKThere is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexeplicable. There is another theory which states that this has already happened. --- Introduction to Fit the Seventh. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Public service announcement about Policy 10.4
Brian M. Carlson wrote: > I would like to point out that the following are not POSIX features: > > local > test -o > test -a Regarding "local", see #294962. I would like to see support for "local" added to posh and "local" added as an exception to the "POSIX-only" rule laid down in 10.4. See #267142 for a long discussion of the "POSIX-only" rule. I support the idea of requiring #!/bin/sh scripts to be runnable on posh. Unfortunately not everyone is prepared to go along with it (e.g., #309415). -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On 20050729T083332+, Brian M. Carlson wrote: > Of course, I could be persuaded that the enumeration is a good idea, but > I don't see what problem it solves, and it only seems to cause them. The anon enumeration trick has been an established C++ idom for years (ISTR, but cannot check now, even Stroustrup himself advocating it). It's a shame if it now suddenly stopped working and is somehow against the standard, even. The problem with #defines is that they're outside the language proper and, for example, pay no attention to namespaces. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Work-needing packages report for Jul 29, 2005
* > The following packages have been given up for adoption: > >compiler (#319801), offered 4 days ago > >eli (#319463), offered 6 days ago > Description: compiler construction kit > Reverse Depends: eli-xtools eli > >lincvs (#319461), offered 6 days ago (non-free) > Description: graphical CVS frontend > >ml (#319801), offered 4 days ago > >re2c (#320283), offered yesterday > Description: Tool for generating fast C-based recognizers > >smlnj (#319801), offered 4 days ago > Reverse Depends: libmlnlffi-smlnj libsmlnj-smlnj libexene-smlnj > ml-nlffigen ml-lex libckit-smlnj ml-yacc ml-burg libcmlutil-smlnj > libpgraphutil-smlnj smlnj nowhere libmlrisctools-smlnj libcml-smlnj > >standard (#319801), offered 4 days ago This looks like some script bug. The subject line of #319801 is: Subject: RFA: smlnj standard ml compiler And the pacakges "standard", "ml" and "compiler" are listed above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC, problem with g++4
On Fri, 29 Jul 2005, Petri Latvala wrote: > One option would be to make wrap take an int always, if that's > feasible. Or long. Or unsigned versions of those. sfs upstream might want to do that for portability. I'm wondering what are the consequences of making that enum named.. can anyone see why not? --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Public service announcement about Policy 10.4
This is a public service announcement about Debian Policy section 10.4,
which states in part:
The standard shell interpreter `/bin/sh' can be a symbolic link to any
POSIX compatible shell, if `echo -n' does not generate a newline.[1]
Thus, shell scripts specifying `/bin/sh' as interpreter should only
use POSIX features. If a script requires non-POSIX features from the
shell interpreter, the appropriate shell must be specified in the
first line of the script (e.g., `#!/bin/bash') and the package must
depend on the package providing the shell (unless the shell package is
marked "Essential", as in the case of `bash').
I have found no less than four packages which break with /bin/posh
as /bin/sh, including one that refuses to be removed because of its
brokenness. I am expecting many more.
I suggest that all maintainers test their packages with /bin/sh
as /bin/posh as well as _POSIX2_VERSION=200112 in their configuration
files. Please be aware that due to debconf brokenness that is caused by
non-POSIX features, if you do set /bin/sh as /bin/posh, you may not be
able to undo this without manually patching debconf or waiting for it to
be fixed. Bugs have already been filed about this (not by me).
I would like to point out that the following are not POSIX features:
local
test -o
test -a
You may fix these bugs by specifying "#!/bin/bash" as the first line of
your script, or you may simply remove these non-POSIX extensions.
I would also like to point out that these bugs are severity not less
than important, so you may want to fix these bugs if they occur in your
packages, even if they have not been filed in the BTS yet.
This ends the public service announcement. Thank you for your attention
to this matter. Have a nice day.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: RFC, problem with g++4
On Fri, 2005-07-29 at 10:55 +0300, Jaakko Niemi wrote:
> Hello,
>
> /usr/include/sys/socket.h has this:
>
> -
> /* The following constants should be used for the second parameter of
>`shutdown'. */
> enum
> {
> SHUT_RD = 0, /* No more receptions. */
> #define SHUT_RD SHUT_RD
> SHUT_WR, /* No more transmissions. */
> #define SHUT_WR SHUT_WR
> SHUT_RDWR /* No more receptions or transmissions. */
> #define SHUT_RDWR SHUT_RDWR
> };
> -
>
> which results into error when compiling sfs with g++ 4.x:
>
> rexchan.C: In member function 'virtual void unixfd::data(svccb*)':
> rexchan.C:254: error: '' is/uses anonymous type
> rexchan.C:254: error: trying to instantiate 'template R, class B1, class A1, class AA1> refcounted B1, A1>, scalar>* wrap(C*, R (C::*)(A1, B1), const AA1&)'
> rexchan.C:254: error: no matching function for call to 'wrap(unixfd*
> const, void (unixfd::*)(int, int), )'
>
> rexchan.C:254 is:
>
> paios_out->setwcb (wrap (this, &unixfd::update_connstate, SHUT_WR));
>
> Now, should libc name that enumeration, g++ generate warning instead
> of error or moon be mined for cheese snacks?
I think the moon should be mined for cheese snacks. No, just kidding.
libc6 should not name an enumeration except either in the implementation
namespace or as required by POSIX.
What I think it should do, and this is JMHO, is just:
#define SHUT_RD 0
#define SHUT_WR 1
#define SHUT_RDWR 2
and leave the enumeration out of it, since it's not required, and can
actually break things, if the values are not within the value of an int.
For example, the Sparc/UltraSparc fpu_control.h.
I definitely like gcc's strictness, so it should definitely be an error.
I think the reason that g++ is so strict on anonymous enums is that it
had problems with mangling their names (since they don't have any name,
it's sort of hard to mangle them). Also, I believe it violates the C++
standard for that very reason.
Of course, I could be persuaded that the enumeration is a good idea, but
I don't see what problem it solves, and it only seems to cause them.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: RFC, problem with g++4
On Fri, Jul 29, 2005 at 10:55:36AM +0300, Jaakko Niemi wrote: > Hello, > > /usr/include/sys/socket.h has this: [anonymous enum def] > rexchan.C:254: error: no matching function for call to 'wrap(unixfd* > const, void (unixfd::*)(int, int), )' > > rexchan.C:254 is: > > paios_out->setwcb (wrap (this, &unixfd::update_connstate, SHUT_WR)); > > Now, should libc name that enumeration, g++ generate warning instead > of error or moon be mined for cheese snacks? Either the first or the third option. The C++ standard clearly says you cannot use an anonymous type as a template argument. One option would be to make wrap take an int always, if that's feasible. Or long. Or unsigned versions of those. -- Petri Latvala signature.asc Description: Digital signature
RFC, problem with g++4
Hello,
/usr/include/sys/socket.h has this:
-
/* The following constants should be used for the second parameter of
`shutdown'. */
enum
{
SHUT_RD = 0, /* No more receptions. */
#define SHUT_RD SHUT_RD
SHUT_WR, /* No more transmissions. */
#define SHUT_WR SHUT_WR
SHUT_RDWR /* No more receptions or transmissions. */
#define SHUT_RDWR SHUT_RDWR
};
-
which results into error when compiling sfs with g++ 4.x:
rexchan.C: In member function 'virtual void unixfd::data(svccb*)':
rexchan.C:254: error: '' is/uses anonymous type
rexchan.C:254: error: trying to instantiate 'template refcounted, scalar>* wrap(C*, R (C::*)(A1, B1), const AA1&)'
rexchan.C:254: error: no matching function for call to 'wrap(unixfd*
const, void (unixfd::*)(int, int), )'
rexchan.C:254 is:
paios_out->setwcb (wrap (this, &unixfd::update_connstate, SHUT_WR));
Now, should libc name that enumeration, g++ generate warning instead
of error or moon be mined for cheese snacks?
--j
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FROM ADDRESS NOT FOUND
This mailing list does not accept messages from email addresses that are not on the mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
