Re: old bugs are still shown on the bugs page

[Don Armstrong]

On Fri, 07 Dec 2007, Kamaraju S Kusumanchi wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339581 has been fixed on
> Apr 17, 2007. But it still shows up in http://bugs.debian.org/texmacs . Is
> this a bug in the BTS or am I missing something stupid?

1:1.0.6-11 is still available in unstable, and that bug is present in
1:1.0.6-11. See the header on that page:

"Bugs in package texmacs (versions 1:1.0.6-11, 1:1.0.6.11-2+b1,
1:1.0.6.11-1, 1:1.0.6.11-2) in unstable"

[There is some argument that I should completely ignore hurd-i386 by
default since it isn't keeping up *at all* but I haven't made that
change yet.]


Don Armstrong

-- 
[Panama, 1989. The U.S. government called it "Operation Just Cause".]
I think they misspelled this. Shouldn't it be "Operation Just 'Cause"?
 -- TekPolitik http://slashdot.org/comments.pl?sid=59669&cid=5664907

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: old bugs are still shown on the bugs page

[Jose Luis Rivas Contreras]

Kamaraju S Kusumanchi wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339581 has been fixed on
> Apr 17, 2007. But it still shows up in http://bugs.debian.org/texmacs . Is
> this a bug in the BTS or am I missing something stupid?

Maybe it's because a version with the bug is still available in
oldstable? Not so sure.

Regards,
Jose Luis.
-- 

ghostbar on debian linux 'sid' 2.6.22 x86_64-SMP - #382503
Weblog: http://ghostbar.ath.cx/ - http://linuxtachira.org
http://debian.org.ve - irc.debian.org #debian-ve #debian-devel-es
San Cristóbal, Venezuela. http://chaslug.org.ve GPG: 0xCACAB118



signature.asc
Description: OpenPGP digital signature

old bugs are still shown on the bugs page

[Kamaraju S Kusumanchi]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339581 has been fixed on
Apr 17, 2007. But it still shows up in http://bugs.debian.org/texmacs . Is
this a bug in the BTS or am I missing something stupid?

thanks
raju

-- 
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


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

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Stefano Zacchiroli]

On Fri, Dec 07, 2007 at 08:23:28AM +0100, Loïc Minier wrote:
>  With constructs like:
> 
> PYVERS := $(shell pyversions -vr debian/control 2>/dev/null)
> 
> build-%:
>   PYTHON=`which python$*` ./configure

I guess this should have been "`which $*` ./configure", right? If so,
read on.

> build: $(PYVERS:%=build-%)
> 
>  And it doesn't even conflict with implemeting build-arch; it just makes
>  the test make moot.

And what would you loose in using something like:

  build-python%:
PYTHON=`which python$*` ./configure
...
  build-arch:
...

?

Cheers

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Bug#107862: bathtub rock clown

[Mac Guy]

Xmas is surely here and it's time to get Shopping
We stock huge amount of gifts for Yourself and your Family and Friends
http://geocities.com/EvanKlein09



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

Re: Please don't list available translations in the package description

[Christian Perrier]

Quoting Francesco P. Lovergine ([EMAIL PROTECTED]):

> I'd also tend to think that generic internationalization support
> sentences are quite inappropriate into package long description.
> Support leve is generally subject to frequent changes, so why
> polluting descriptions with those things?


Sustained 200%.

For the record, when we come on such things in the Smith Project
(where we review debconf templates and, while we're at it, packages
descriptions), we propose maintainers to drop the relevant part and
use a more generic statement abou tthe software's i18n.

Indeed, any information that is likely to change over time should just
go away from packages' descriptions, as much as possible.

This also stands for statements like "Package  does this and
that and will probably do  in the near future".




signature.asc
Description: Digital signature

Using sgid binaries to defend against LD_PRELOAD/ptrace()

[Martin Pitt]

Hi all,

one thing that has bothered me for a long time already is the
complete lack of a security boundary between processes of the same
user. Things like LD_PRELOAD and ptrace() (IOW, gdb) are enabled by
default for all users, and especially for developers this is a good
thing.

However, a lot of programs that we have deal with passwords and other
secrets which deserve some protection, like passwords you type into
ssh, screensavers, seahorse, etc.

This problem has become more pressing with the advent of PolicyKit,
where even fewer processes have the in-built privilege separation
between root and users. Getting rid of a lot of instances of
gksu/kdesu is great, of course. :) [1]

This concerns a scenario where you might have a rogue trojan in your
session (e. g. a malicious firefox plugin or an autostart shell
script). Admittedly, if an attacker gets that far he has almost won
the machine and can easily get more privileges with some social
engineering and spoofing, but I feel it is worth the small effort to
at least not allow reading passwords from other processes' memory
without making any noise at all.

One easy solution that comes to my mind is to install those affected
programs setgid, and drop the additional group immediately after
program start with setgid(getgid()). For this we should introduce a
new static group into base-passwd, like "noptrace", to not abuse
existing groups and not confuse auditing tools.

Setgidness provides a robust way to disallow ptrace/LD_PRELOAD for
the user's peer processes without disabling them in general. (Note
that all attempts to disable ptrace() within the program itself, such
as prctl(SET_DUMPABLE, 0) are subject to race conditions and won't
help).

Another option would be to introduce a sysctl for enabling ptrace for
users and disable it by default, but that would just mean that every
developer get immediately frustated about gdb not working and enable
it again at instant, so that you don't end up with any protection at
all. Providing the sysctl would be useful anyway for servers, but
disabling it by default is a bad idea I think.

So I am asking for the addition of a new static group with this
purpose. Once we have that, we can convert specific packages to use
that setgid trick.

What do you think about this approach? I'm well aware that this alone
won't rescue desktop security (getting there is looots of more work),
but one has to start somewhere.

Thanks in advance for any comments,

Martin

P.S. Please keep me in CC.

[1] gksu's security properties are just *so* horrible... That program
is a mess. (I haven't looked at kdesu, but I guess it's not much
better)

-- 
Martin Pitthttp://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org


signature.asc
Description: Digital signature

Bug#206187: salt butterfly

[Cyril Page]

Xmas is surely here and it is time to Shop
We have immense collection of gifts for your self and your Family and Friends
http://geocities.com/DannieMcgee71



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

Re: Please don't list available translations in the package description

[Osamu Aoki]

On Fri, Dec 07, 2007 at 03:10:35PM +0100, Francesco P. Lovergine wrote:
> On Fri, Dec 07, 2007 at 01:40:43PM +, Stephen Gran wrote:
> > This one time, at band camp, Leo costela Antunes said:
> > > Enrico Zini wrote:
> > > > I'm thinking of filing bugs, but I'd like to get some feedback here
> > > > first.
> > > 
> > > While I agree it's an issue (albeit a small one), I think we shouldn't
> > > file bugs for it while there's no better place to put this information.
> > > It may reduce the objectiveness of some searches, but it is still
> > > valuable information.
> > 
> > At the moment, I'm inclined to agree with Enrico.  I don't think it's
> > all that helpful to have some small subset of all the programs actually
> > translated into a given language returned in a search for that language
> > string.  It's both an incomplete list (since many other programs will be
> > localized, but just not mention it in the package description) and also
> > useless clutter when you're looking for things related to actually
> > working in the language.
> 
> I'd also tend to think that generic internationalization support
  ^^^ yes.
> sentences are quite inappropriate into package long description.
> Support leve is generally subject to frequent changes, so why
> polluting descriptions with those things?

I agree.  Since most of the packages understand UTF-8 these days for
i12n, there is no need to mention each l10n support.  

(In old days, jvim was different from vim to support Japanese ... I do
not know if it ever reached debian.org or stayed in debian.or.jp...
though)

Osamu


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

Re: Injecting versions of build-deps in the deps

[Loïc Minier]

On Fri, Dec 07, 2007, Raphael Hertzog wrote:
> libgtk-x11-2.0.so.0 libgtk2.0-0 #MINVER#
> * Devel-Package: libgtk2.0-dev
>  [EMAIL PROTECTED] 2.8.0
>  ...
> How does that sound ?

 Sounds like a good start!  Perhaps the injection should be explicitely
 requested with:
  * UseBuildDepVersionAsMinVer: yes
 or the field could be named to reflect that it's used for bdeps:
  Build-Depends-Package: libgtk2.0-dev


 I think build-deps-indep don't need to be checked since we're
 targetting shlib:Depends which are usually in arch: any packages.
   I couldn't find a use for honoring build-conflicts -- generating
 conflicts isn't supported by the shlib/symbol system ATM anyway.
   So it only leaves dealing with multiple bdeps: I suppose they could
 all be copied over and will generate the same warning that the
 duplicate build-dep.

-- 
Loïc Minier


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

Re: Please don't list available translations in the package description

[Enrico Zini]

On Fri, Dec 07, 2007 at 02:22:49PM +0100, Leo costela Antunes wrote:

> Couldn't debtags support this sort of information in a good enough way
> (not via culture::*, but something like translated-in::*)?
> Or perhaps - if stricter solution is desired - implementing a new
> control field that could be filled on build-time by a dh script (which
> should support po files natively, but could also support regex based
> searching of translation files, for alternative translation schemes)?

I don't think it's a good idea to use Debtags: it would immensely
clutter the Packages file, and the workflow for Debtags tags isn't ideal
for this.

Also, maybe with locales one would like to match more smartly than you
do with tags: maybe if I'm looking for it_CH I could be happy to find
another it_IT if it_CH is missing.

The feature is interesting, though.  I didn't know of
http://www.debian.org/intl/l10n/po/ posted by cobaco, and that could be
leveraged.  I'm thinking fetching info from
http://www.debian.org/intl/l10n/po/ and feeding them into
apt-xapian-index, for example.

If someone explains me precisely how locales are supposed to match, I
can work out a nice way of doing that.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Please don't list available translations in the package description

[cobaco (aka Bart Cornelis)]

On Friday 07 December 2007, Leo "costela" Antunes wrote:
> Enrico Zini wrote:
> > I'm thinking of filing bugs, but I'd like to get some feedback here
> > first.
>
> While I agree it's an issue (albeit a small one), I think we shouldn't
> file bugs for it while there's no better place to put this information.
> It may reduce the objectiveness of some searches, but it is still
> valuable information.

Almost no packages currently do this, hence relying on the package 
description to check wether a package is localized for your language is 
completely unreliable.

For a list of localised packages check http://www.debian.org/intl/l10n/po/ 
for your language, true it only cover's gettext localisations but that's 
99% of all localisation in free software anyway (this misses some localised 
webapps but that's about it AFAIK)

For a specific package you can also use apt-file or packages.debian.org to 
check for the presence of a .po file for your language.
-- 
Cheers, cobaco (aka Bart Cornelis)


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

Re: priorities

[NN_il_Confusionario]

On Fri, Dec 07, 2007 at 07:28:22PM +1000, Anthony Towns wrote:
> both required and base in the same list, so you have to look for the split
> yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.

Yes it is not _hard_, but it is exactly this sort of dependency hunting
that is uselessy time consuming, since for each _released_ debian (etch,
sarge, woody, ...) such a list is fixed and "already known"; having to
rediscover it each time is not the smartest thing.

In pratice, the fastest solution for me has been up to now to use
debootstrap, then install deborphan in the chroot to purge things. And
finally a tar of the "essential" chroot (without
var/cache/apt/archives/*.deb var/lib/apt/lists/*_{Release,Packages} and
so on). But then Murphy assures that sooner or later you will need a new
architecture or a new release or to install a machine without access to
the machine where the tar is saved ...

However, many tanks for your patch.

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


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

Re: Please don't list available translations in the package description

[Francesco P. Lovergine]

On Fri, Dec 07, 2007 at 01:40:43PM +, Stephen Gran wrote:
> This one time, at band camp, Leo costela Antunes said:
> > Enrico Zini wrote:
> > > I'm thinking of filing bugs, but I'd like to get some feedback here
> > > first.
> > 
> > While I agree it's an issue (albeit a small one), I think we shouldn't
> > file bugs for it while there's no better place to put this information.
> > It may reduce the objectiveness of some searches, but it is still
> > valuable information.
> 
> At the moment, I'm inclined to agree with Enrico.  I don't think it's
> all that helpful to have some small subset of all the programs actually
> translated into a given language returned in a search for that language
> string.  It's both an incomplete list (since many other programs will be
> localized, but just not mention it in the package description) and also
> useless clutter when you're looking for things related to actually
> working in the language.

I'd also tend to think that generic internationalization support
sentences are quite inappropriate into package long description.
Support leve is generally subject to frequent changes, so why
polluting descriptions with those things?

-- 
Francesco P. Lovergine


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

Re: Please don't list available translations in the package description

[Michael Banck]

On Fri, Dec 07, 2007 at 10:52:08AM +, Enrico Zini wrote:
> ldap-account-manager is not the only package doing this: a quick search
> gives me [...] gperiodic

I removed that in svn.


Michael


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

Re: Please don't list available translations in the package description

[Leo "costela" Antunes]

Stephen Gran wrote:
> At the moment, I'm inclined to agree with Enrico.  I don't think it's
> all that helpful to have some small subset of all the programs actually
> translated into a given language returned in a search for that language
> string.  It's both an incomplete list (since many other programs will be
> localized, but just not mention it in the package description) and also
> useless clutter when you're looking for things related to actually
> working in the language.

Don't get me wrong, I agree with your assessment, I just think we could
come up with a better place to put this information _before_ filling
bugs. They may not be in the right place, but it's useful information
that IMHO should be accessible somewhere so that our users don't have to
go hunting for it on the web or are forced to install packages to check
it out.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Injecting versions of build-deps in the deps

[Raphael Hertzog]

On Fri, 07 Dec 2007, Loïc Minier wrote:
>  I do imagine it wont be mandatory (or useful) for all libs as well and
>  I agree it should be added on a per package basis; one idea I
>  mentionned to Raphaël is to extend the shlibs / symbols system to allow
>  a syntax meaning "Take the build-dep version" instead of having a fixed
>  version; that is, instead of:
> libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.12.0)
>  we might have some macros like:
> libgtk-x11-2.0 0 libgtk2.0-0 (>= $Build-Depends{libgtk2.0-dev})
> 
>  Can be seen as "dynamic shlibs" or "shlibs macros".  (Or symbols.)

The only thing I really lack with symbols files is the mapping library ->
-dev package. Thus I'd suggest to simply add this information in a new
"header" line in the symbols file:

libgtk-x11-2.0.so.0 libgtk2.0-0 #MINVER#
* Devel-Package: libgtk2.0-dev
 [EMAIL PROTECTED] 2.8.0
 ...

The initial "*" is just there to make it clear to the parser that we're
not starting to list a new library but a header and "|" is already used
for alternate dependency templates. If the field is not there, then
there's no check of the build-depends version.

The feature is not that important for packages using shlibs since
they get strong dependency by default and it's fine that way.

How does that sound ?

Cheers,
-- 
Raphaël Hertzog

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


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

Re: Please don't list available translations in the package description

[Leo "costela" Antunes]

cobaco (aka Bart Cornelis) wrote:
> Almost no packages currently do this, hence relying on the package 
> description to check wether a package is localized for your language is 
> completely unreliable.

Agreed.

> For a list of localised packages check http://www.debian.org/intl/l10n/po/ 
> for your language, true it only cover's gettext localisations but that's 
> 99% of all localisation in free software anyway (this misses some localised 
> webapps but that's about it AFAIK)
> 
> For a specific package you can also use apt-file or packages.debian.org to 
> check for the presence of a .po file for your language.

These are hardly practical solutions from a user perspective, even
though they are very helpful for developers.

What I meant is that I believe in the need for a way to tell users which
languages the package they intend to install supports (which doesn't
include greping for the package in a separate huge list of for files in
the source ;-) )

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Please don't list available translations in the package description

[Stephen Gran]

This one time, at band camp, Leo costela Antunes said:
> Enrico Zini wrote:
> > I'm thinking of filing bugs, but I'd like to get some feedback here
> > first.
> 
> While I agree it's an issue (albeit a small one), I think we shouldn't
> file bugs for it while there's no better place to put this information.
> It may reduce the objectiveness of some searches, but it is still
> valuable information.

At the moment, I'm inclined to agree with Enrico.  I don't think it's
all that helpful to have some small subset of all the programs actually
translated into a given language returned in a search for that language
string.  It's both an incomplete list (since many other programs will be
localized, but just not mention it in the package description) and also
useless clutter when you're looking for things related to actually
working in the language.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Please don't list available translations in the package description

[Leo "costela" Antunes]

Enrico Zini wrote:
> I'm thinking of filing bugs, but I'd like to get some feedback here
> first.

While I agree it's an issue (albeit a small one), I think we shouldn't
file bugs for it while there's no better place to put this information.
It may reduce the objectiveness of some searches, but it is still
valuable information.

Couldn't debtags support this sort of information in a good enough way
(not via culture::*, but something like translated-in::*)?

Or perhaps - if stricter solution is desired - implementing a new
control field that could be filled on build-time by a dh script (which
should support po files natively, but could also support regex based
searching of translation files, for alternative translation schemes)?

IMHO the debtags solution looks simpler and better, but it doesn't hurt
to keep our options open! :-)

Cheers
-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Please don't list available translations in the package description

[Enrico Zini]

Hello,

I'm reviewing tag submissions and I noticed that people added lots of
culture::* tags to a non culture specific package like
ldap-account-manager.  The reason was simple: the description mentions:

  LAM is translated to Catalan, Chinese (Simplified + Traditional),
  Czech, Dutch, English, French, German, Hungarian, Italian, Japanese,
  Portuguese, Russian and Spanish.

This shows that people are lead into thinking that the package provides
special support for those cultures.  Read on for what I mean with
'special support'.

I don't think that this is a useful piece of information for a package
description: people doing "apt-cache search japanese" are likely not to
expect to see ldap-account-manager among the results: what one would
expect to see is dictionaries, input methods, festival modules, latex
styles and similar things.

If we want to implement a feature such that we can see what packages are
localised for a given language, that should be done differently, most
likely by building a database scanning what .po files are present in the
source package.

ldap-account-manager is not the only package doing this: a quick search
gives me sitemap, worker, easytag, gperiodic, ri-li and sailcut; there
are more, but unfortunately I can't provide a comprehensive list as it's
hard to spot these cases automatically.

I'm thinking of filing bugs, but I'd like to get some feedback here
first.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Injecting versions of build-deps in the deps

[Loïc Minier]

On Fri, Dec 07, 2007, Colin Watson wrote:
> I wonder if the objections raised to this suggestion could be addressed
> by making it optional in some way - perhaps either by requiring it to be
> manually enabled for each library by some kind of shlibs/symbols-like
> system, or by providing support for libraries to declare themselves
> exempt from it.

 I do imagine it wont be mandatory (or useful) for all libs as well and
 I agree it should be added on a per package basis; one idea I
 mentionned to Raphaël is to extend the shlibs / symbols system to allow
 a syntax meaning "Take the build-dep version" instead of having a fixed
 version; that is, instead of:
libgtk-x11-2.0 0 libgtk2.0-0 (>= 2.12.0)
 we might have some macros like:
libgtk-x11-2.0 0 libgtk2.0-0 (>= $Build-Depends{libgtk2.0-dev})

 Can be seen as "dynamic shlibs" or "shlibs macros".  (Or symbols.)

 [ NB: this is overly simplistic as a package can have duplicate
  build-depends like libgtk2.0-dev >= 1, libgtk2.0-dev >= 2, or
  libgtk2.0-dev << foo, and there are build-conflicts and
  build-deps-indep as well ]



 In the last week, I came up with many crackful ideas which most people
 should ignore for the time being, but which some will find funny:
   instead of defining a complex syntax, we could as well allow for
 dpkg-shlibdeps to be extended to call some hook when a particular
 SONAME dep is encounted.  Some kind of plugins mechanisms to allow some
 specialized code provided by the libfoo maintainer to be run when a
 libfoo dep is encountered.

   This code could be based on API provided by dpkg-shlibdeps for most
 things.  The plugin interface could be as simple as:
onShlibDep($needed, $pathname) {};

 with libgtk2.0-dev declaring in shlibs:
libgdk-x11-2.0 0 run:gtk-shlibdep
 or:
dynshlibs: libgdk-x11-2.0 0 gtk-shlibdep

 implemented as:
onShlibDep($nedeed, $package, $pathname) {
my $ver = getBuildDepsVer("libgtk2.0-dev");
addDepends($package, "libgtk2.0-0 (>= $ver)");
};

 Concrete advantage over the non-crackful idea?  I guess none at the
 moment, but yours to imagine!

-- 
Loïc Minier


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

Re: Injecting versions of build-deps in the deps

[Colin Watson]

On Mon, Dec 03, 2007 at 06:38:20PM +0100, Julien Cristau wrote:
> On Mon, Dec  3, 2007 at 17:33:41 +0100, Josselin Mouette wrote:
> > Every successful call to pkg-config would fill in a file, let’s say
> > debian/pkgconfig.deps, that would in the end contain:
> > 
> > # pkgconfig_file required_version dev_package shared_package
> > version
> > x11 1.0.2 libx11-dev libx11-6 2:1.0.3-7
> > gtk+2.0 2.8 libgtk2.0-dev libgtk2.0-0 2.12.2-1
> > gconf 2.0 libgconf2-dev libgconf2-4 2.20.1-1
> > (The package version is needed because you need to extract epochs.)
> > 
> > In the end, shlibs generation would be able to generate the correct
> > dependency, based on the highest of the three versions:
> >  1. the version required by upstream;
> >  2. the version required by the build-deps;
> >  3. the version generated by the symbols file.
> > 
> > Plus, in this specific case, it would make the build fail because the
> > Debian maintainer has forgotten to bump the libx11-dev build-dependency
> > to 2:1.0.2, which is deadly useful information.
> 
> Why would you depend on any particular version of libx11-6?  The
> build-dep on libx11-dev >= 1.0.2 I can understand, but the runtime
> dependency has nothing to do with this.

For those of us less familiar with X, could you clarify why you wouldn't
want a run-time dependency if the upstream configure.ac says
PKG_CHECK_MODULES(FOO, x11 >= 1.0.2)? That is, what might they need at
build-time that they wouldn't need at run-time?


I like Loïc's idea in general; I know that build-time and run-time
dependency versions are conceptually distinct but they're not entirely
unrelated either. Raphaël's recent changes to dpkg-gencontrol to
simplify dependencies also help by making it straightforward to add an
explicit dependency in debian/control without worrying about whether
people are going to file bugs due to a duplicated dependency.

I wonder if the objections raised to this suggestion could be addressed
by making it optional in some way - perhaps either by requiring it to be
manually enabled for each library by some kind of shlibs/symbols-like
system, or by providing support for libraries to declare themselves
exempt from it.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: ITP: squeak-vm -- Virtual machine needed to run Squeak images on unix

[L. Redrejo]

El vie, 07-12-2007 a las 10:57 +0100, Bernd Zeimetz escribió:
> > * License : MIT
> 
> hmm, on a fast look trough the tarball all I found was
> - a LICENSE file, with a license from Apple
> - a COPYING file, with a license which seems to be written by squeak
> (starts pretty ugly, didn't read it, though).
> - a COPYRIGHT file which contains the GPL2
> 
> and no license information at all in the randeom ~10 source files I
> looked into.
> 
> Looks like http://www.debian.org/devel/wnpp/unable-to-package is still
> correct - but it would be a good thing to convince upstream to fix that.
> 

I'm afraid you've looked at the version 3.9-8 whose tarball is available
at the official web page. My plan is package 3.9-12 (available through
svn) that has fixed those files.

Cheers.
BTW: Upstream is totally convinced.



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: ITP: squeak-vm -- Virtual machine needed to run Squeak images on unix

[L. Redrejo]

El jue, 06-12-2007 a las 23:00 +0100, Daniel Baumann escribió:
> squeak is supposed[0] to be unable to package for debian due to legal
> reasons. can you elaborate on the current status?
> 
> [0] http://www.debian.org/devel/wnpp/unable-to-package
> 

Sure:
Squeak is being relicensed from the old Apple license to a MIT license.
There have been some hundred of code contributors[1] and most of them
have already signed to relicense it. There is still some parts of the
code whose authors haven't answer to that requirement [2] and  parts of
the code is going to be rewritten or removed from Squeak. So Squeak as a
whole can not be uploaded to Debian yet. 
But all the virtual machine code is already under MIT [3] and available
under svn [4]. That's why I plan to upload only squeak-vm and not any
Squeak image to Debian. With the squeak-vm any Squeak image can be run:
the official one that's not DFSG compatible yet, but also some others
images that are totally free now [5]
Anyway I'm optimistic and I think that the whole Squeak image will be
available under MIT quite soon, as all the reimaining code and licenses
issues are being studied and fixed by the community and the Software
Freedom Law Center.

I know the whole Squeak paradigm it's a little hard to understand to
those that are not familiar with its use (the concept of program itself
is not the same as with "normal" languages, same for the image or the
vm), but I hope it's clearer now.

Regards.
José L.

[1]http://netjam.org/squeak/contributors/
[2]
http://article.gmane.org/gmane.comp.lang.smalltalk.squeak.general/120620
[3]http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/unix/doc/LICENSE?rev=1569&view=auto
[4]http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/
[5]http://www.squeaksource.com/KernelImage.html


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: ITP: squeak-vm -- Virtual machine needed to run Squeak images on unix

[Bernd Zeimetz]

> * License : MIT

hmm, on a fast look trough the tarball all I found was
- a LICENSE file, with a license from Apple
- a COPYING file, with a license which seems to be written by squeak
(starts pretty ugly, didn't read it, though).
- a COPYRIGHT file which contains the GPL2

and no license information at all in the randeom ~10 source files I
looked into.

Looks like http://www.debian.org/devel/wnpp/unable-to-package is still
correct - but it would be a good thing to convince upstream to fix that.


Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Sheldon Hearn MIA?

[Philipp Marek]

Hello Thomas,
> On Friday 07 December 2007 01:02:14 Thomas Viehmann wrote:
> > He seems to have progressed in creating packages because there is an
> > (unanswered) request to sponsor (upload) them[1].
> >
> > He also posted to debian-kernel in mid-October[2].
yes, thank you - he's back :-)


Hello Sheldon!

On Friday 07 December 2007 Sheldon Hearn wrote:
> My company's been busy with a bid on a government tender to set up an
> ISP for provincial schools.  It's been... a lot of work. :-)
>
> I notice that I didn't update the bug with a reference to the uploaded
> packages.  I've now done that.
>
> So now I think it's just a case of waiting for a DD to take interest.
>
> I think fsvs is going somewhere; it certainly solves a particular
> problem in a way that nothing else I've seen quite gets right.
That's why I wrote it :-)

Welcome back!


Regards,

Phil


-- 
Versioning your /etc, /home or even your whole installation?
 Try fsvs (fsvs.tigris.org)!


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

Re: Proposalto introduce compiler options passed from dpkg-buildpackage

[Colin Watson]

On Tue, Dec 04, 2007 at 08:50:15PM +0100, Frank Lichtenheld wrote:
> On Tue, Dec 04, 2007 at 05:08:13PM +0100, Matthias Klose wrote:
> > === Alternate naming of the macros ===
> > 
> > Do omit the '''DEB_HOST_''' prefix and all packages should honour the
> > value of CFLAGS etc. in the environment. Many packages are likely to
> > do this by accident anyway. For packages that set CFLAGS etc., there
> > are basically two common cases:
> [...]
> > It has the disadvantage that these macros might be injected into the
> > build for some non-standard build systems.
> 
> If we would choose to use the common names without DEB_HOST_ prefix
> should dpkg-buildpackage then honor them if they are already set in
> the environment? Probably not as this seems error prone.

FWIW, I suggested this because I think it's a lot less work to fix up
the specific packages that get this sort of thing wrong than to enhance
nearly every package in the archive to support a whole new environment
variable naming scheme, go round checking that they support all the
things you care about (since you'd have to deal with them all
individually, support special debian/rules fragments to do this for
evermore, and so on. It just seems an order of magnitude less work to
say "thou shalt honour CFLAGS etc. if they're set in the environment",
and much more in line with how build systems often already work.

What possible errors are you thinking of, other than "debian/rules fails
to honour a certain variable" (i.e. the status quo)? I can't really
think why you'd set CFLAGS in the environment without wanting it to be
honoured.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: priorities

[Anthony Towns]

On Fri, Dec 07, 2007 at 08:25:05AM +0100, NN_il_Confusionario wrote:
> Question: is there somewhere on the net a script (*) such that:
> * it installs required/essential packages (_all_ of them but _only_
>   them) of such a release as a chroot in that directory

You could create a variant for debootstrap. That's not very hard,
depending on your mood:

# cp /usr/share/debootstrap/scripts/sid my-sid
# patch  Every time I do someting like that, too much time is spent for
> dependency hunting. Ad every time I forget to save the list of packages :-(

debootstrap --print-debs will give you a list of packages. It includes
both required and base in the same list, so you have to look for the split
yourselve (zlibg1 and adduser atm), but that's not too hard hopefully.

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[Anthony Towns]

On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote:
> Frankly, I suggest we look at the list of Unix commands as
>  specified by the SUS -- which can also be seen at:
>http://en.wikipedia.org/wiki/List_of_Unix_programs
> So -- how many of the standard unix commands as defined by that
>  page are not part of the standard section?

I guess one of the the things I wonder every now and then
is whether we really should be keeping standard as implying a
... traditional/historical/whatever Unix system, with pr and lpr and tcsh
and bc and dc and whatever else that people would traditionally expect,
instead of moving them to a task that can be installed only by people
who actually know what they are, and then making sure we provide a real
Unix system in that case. But by the looks of things there's still not
much need for a change there, at least at this point.

Cheers,
aj



signature.asc
Description: Digital signature

Re: priorities

[NN_il_Confusionario]

On Fri, Dec 07, 2007 at 04:37:57PM +0900, Michal ??iha?? wrote:
> On Fri, 7 Dec 2007 08:25:05 +0100
> NN_il_Confusionario <[EMAIL PROTECTED]> wrote:
> > * it installs required/essential packages (_all_ of them but _only_
> >   them) of such a release as a chroot in that directory
> Isn't minimal flavour in cdeboostrap doing this?

the man page says:

   minimal
  Installs  essential and apt. 

so it should do _almost_ what I asked, but not exactly: at least apt and
its dependencies are added to dpkg and its dependencies.

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


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

Re: priorities

[Michal Čihař]

Hi

On Fri, 7 Dec 2007 08:25:05 +0100
NN_il_Confusionario <[EMAIL PROTECTED]> wrote:

> Question: is there somewhere on the net a script (*) such that:
> 
> * it accepts two parameters: a debian release (etch, sarge, woody, ...)
>   and an (empty) directory;
> 
> * it installs required/essential packages (_all_ of them but _only_
>   them) of such a release as a chroot in that directory
> 
> ? [Mybe also a third parameter will be useful, the architecture]
> 
> (*) complete and explicit lists to use with debootstrap are a solution.
> (debootstrap by default installs quite more than really
> required/essential packages).
> 
> Every time I do someting like that, too much time is spent for
> dependency hunting. Ad every time I forget to save the list of packages :-(

Isn't minimal flavour in cdeboostrap doing this? So the script would
be: "cdebootstrap -f minimal sid /tmp/foobar".

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature