Re: [GSoC] KDE4/Qt4 based package manager

[Christian Perrier]

Quoting Obey Arthur Liu (art...@milliways.fr):

> > synaptic or shaman (from Chakra). I think that aptitude-gtk and adept
> > are not userfriendly. Using these applications was quite difficult for
> Heartfelt thank yous! (I'm the guy responsible for aptitude-gtk.. :D )


Is this silly to think that, as most of the (good) work was made in
aptitude-gtk, an aptitude-qt development would be a better idea?

Aptitude has all the nice underlying package management stuff and that
would avoid reinventing the wheel.



signature.asc
Description: Digital signature

Re: why is Ardour pretty outdated in stable and not in testing?

[Fabian Greffrath]

Grammostola Rosea schrieb:
But that doesn't really solve the problem imo. The problem is solved 
when Ardour in unstable hit testing and then stable after a while. Now 
it seems to be stuck in unstable...


You don't seem to understand the Debian release policy. Once a stable 
version has been released, there is zero chance that another package 
will be added. The only chance for ardour to be part of a stable 
Debian release is Squeeze, not Lenny.


--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  greffr...@leat.ruhr-uni-bochum.de


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

Re: grouping of alternative depends

[Stefano Zacchiroli]

On Sun, Mar 29, 2009 at 11:41:22AM +0100, Holger Levsen wrote:
> I'd like to use a depends like "(pdns-backend-ldap pdns-recursor) | bind9" 
> but 
> afaik this is not possible. AFAICS I should file a wishbug against dpkg but 
> as I dont have time atm to dig through all the bugs against dpkg, I thought I 
> drop a mail here, in the hope that someone will point me to an already 
> existing bug or if not, just submit this. TIA.

The solution to this and similar problems are always, as pointed out
by specific solutions in this thread by others, to turn your
dependency formula into conjunctive normal form (CNF) [1], which is
always possible, though possibly ugly, as you observed.

Note that if you want to go the "wishlist bug" path however, the bug
should not be against dpkg, but rather against policy. The reason
being that policy currently only allows dependency formulae in
conjunctive normal form.

Cheers.

[1] http://en.wikipedia.org/wiki/Conjunctive_normal_form

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: realtime kernel for Debian

[Alexander Reichle-Schmehl]

Hi!

Uwe Kleine-König schrieb:

> [your To: header was strange, maybe my mail reaches less recipents than
> your's]

Well, at least it reached me ;)

>>> Maybe providing a patch package is a better first step?
>> thanks for thinking. Who could provide such a patch package?
> I can.  I'd need a sponsor, though.  I know two Debian developers, I
> will ask them.

Willing to sponsor as soon as you've got a package to test ready.


Best regards,
  Alexander



signature.asc
Description: OpenPGP digital signature

Re: why is Ardour pretty outdated in stable and not in testing?

[Andreas Tille]

On Mon, 30 Mar 2009, Fabian Greffrath wrote:

You don't seem to understand the Debian release policy. Once a stable version 
has been released, there is zero chance that another package will be added. 
The only chance for ardour to be part of a stable Debian release is Squeeze, 
not Lenny.


There is backports.org which is a quite canonical place for people to seek
for backports of Debian packages.  Several people do include it in their
sources.list.  I'd prefer up to date packages there instead of "random" other
locations (and yes I know that 64studio is no "random" location for multimedia
experts - but obviosely there are Debian users who did not noticed it there ...)

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: [GSoC] KDE4/Qt4 based package manager

[Obey Arthur Liu]

Christian Perrier a écrit :
> Quoting Obey Arthur Liu (art...@milliways.fr):
> 
>>> synaptic or shaman (from Chakra). I think that aptitude-gtk and adept
>>> are not userfriendly. Using these applications was quite difficult for
>> Heartfelt thank yous! (I'm the guy responsible for aptitude-gtk.. :D )
> 
> 
> Is this silly to think that, as most of the (good) work was made in
> aptitude-gtk, an aptitude-qt development would be a better idea?
> 
> Aptitude has all the nice underlying package management stuff and that
> would avoid reinventing the wheel.

This issue has been discussed too. The decision isn't simple.

The actors:
- Synaptic
Some people don't like it, that's all I will say :)

- Aptitude(-gtk)
Aptitude-gtk is still a development branch, targeted for stable in
Squeeze. Beside the new GTK+ GUI, Daniel Burrows is currently spending
time on heavy development on the resolver to make it faster, more
predictable and so on, plus a few other things. Daniel will not have the
time to manage the development of two graphical interfaces (in addition
to the console and ncurses interfaces..) at once.
Also, due the way the aptitude-gtk interface had been designed, not a
great amount of the code that has been written last summer can be easily
reused for a Qt interface. There has never been any plans to handle more
than one GUI at once in the codebase (3 UIs is already quite a lot).

- Adept 3.0
Petr Rockai had been working on Adept 3.0, a complete rewrite of Adept
with Qt4 and a different, more task-based, interface. Petr has since
stopped the development of Adept[3] at beta~4, citing the choice of
PackageKit as default on Ubuntu as a reason. He's open to giving
maintainership to another developer and the code is in good shape.

- (K)PackageKit
Please Google or read MLs or whatever to understand why this is a..
suboptimal solution.

My opinion on this is that, even if Debian defaults on Gnome, KDE users
should be on a equal footing. They shouldn't be more forced to use a
GTK+ package manager than Gnome users should be forced to us a Qt
package manager. For the sake of simplicity, I realize that I am
approximating out users of other WMs.

Note that Adept 3 has a different UI paradigm than aptitude(-gtk), so it
should be interesting to explore in its own sake. Also, Petr Rockai has
been maintaining libept[4] (with Enrico Zini), a high-level package
management library, that is commonly used by Aptitude and Adept and has
also been orphaned, so there's a little more interest to it here.

Furthermore, there is a possibility that in the future, the (new and
currently developed) dependency resolver of Aptitude would spun out in
its own library so that other package managers, like Adept 3, can use it.

Heard of apt-xapian-index[5] ? Want useful a ranking of package search
results in Aptitude ? in packages.debian.org ? Want to index changelogs,
descriptions ? With keyword highlighting ?

There's definitely a lot of fascinating development perspective around
package management. What do you all think ?

Cheers

Arthur

[1]

[2]

[3] 
[4] 
[5] 

-- 
Obey Arthur Liu




signature.asc
Description: OpenPGP digital signature

Re: why is Ardour pretty outdated in stable and not in testing?

[Grammostola Rosea]

Fabian Greffrath wrote:

Grammostola Rosea schrieb:
But that doesn't really solve the problem imo. The problem is solved 
when Ardour in unstable hit testing and then stable after a while. 
Now it seems to be stuck in unstable...


You don't seem to understand the Debian release policy. Once a stable 
version has been released, there is zero chance that another package 
will be added. The only chance for ardour to be part of a stable 
Debian release is Squeeze, not Lenny.



I understand it. But my point still is there...
Also maybe Debian can be a bit less conservative when such a core app is 
not in stable and stable releases go out the door after years! I guess 
some packages are added in Etch after a while.


But main point is, that Ardour should hit testing after a while.

Kind regards,

\r


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

Re: Bug#519070: fixed in raptor 1.4.18-2

[Rene Engelhard]

Hi,

Michael Biebl wrote:
> > - build against OpenSSL versions of curl and (especially) neon again
> >   as the webdav ucp now directly links against openssl...
> >   (reopens: #391671). Use system-openssl.
> > 
> 
> Why can't you build-depend on libcurl4-gnutls-dev?

Oh, I can, and actually I'll do that (see 
http://lists.debian.org/debian-openoffice/2009/03/msg00443.html), but that will 
cause OOo to link
agsinst both openssl (directly) and  gnutls (via curl). I don't think
that is perfect :-)

> I agree, that the current situation wrt to libcurl sucks.
> But I definitely think that libraries (such as libraptor) should link against
> the gnutls version of libcurl, otherwise you get the previous situation where
> packages will start to link against OpenSSL (via indirect dependencies) 
> without
> having the proper OpenSSL exemption and thus are not distributable.
> So imho  libcurl4-gnutls should be preferred where possible.

I also agree with that, and it was a totally braindead decision for OOo
to start using OpenSSL instead of GNUTLS...

Grüße/Regards,

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


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

Re: grouping of alternative depends

[Goswin von Brederlow]

Holger Levsen  writes:

> Hi,
>
> On Sonntag, 29. März 2009, Emilio Pozuelo Monfort wrote:
>> Doesn't this do what you want?
>> Depends: pdns-backend-ldap | bind9, pdns-recursor | bind9
>
> sure, that works and thats what I'm doing now. But it's ugly and redudant and 
> potentially wrong: installing pdns-backend-ldap and bind9 satisfies that 
> depends, but not my needs...
>
>
> regards,
>   Holger

Then what you are missing is

Conflicts: pdns-backend-ldap & !pdns-recursor, pdns-recursor & 
!pdns-backend-ldap

which dpkg can not express.

MfG
Goswin


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

Re: why is Ardour pretty outdated in stable and not in testing?

[Ben Finney]

Grammostola Rosea  writes:

> Also maybe Debian can be a bit less conservative when such a core
> app

I think Ardour is pretty far from “a core app”. That term should be
reserved for nigh-indispensible applications like the MTA or even the
well-named ‘coreutils’.

> is not in stable and stable releases go out the door after years! I
> guess some packages are added in Etch after a while.

As has been explained several times, Debian stable releases *do not*
get new packages added. Only security updates and grave bug fixes to
*existing* packages in that release; that guaranteed resistance to
change is precisely what is meant by referring to them as “stable”.

Currently, Debian Etch (4.0), released 2007-04-08, is the ‘oldstable’
release, and Debian Lenny (5.0), released 2009-02-14, is the ‘stable’
release. They will not be getting any packages added, since they are
released.

Debian Squeeze is the current ‘testing’ branch. It will become the
next release, once it is declared ready. For now, new packages can
enter it, according to certain criteria.

> But main point is, that Ardour should hit testing after a while.

It may do so, if it enters ‘unstable’ first and then meets all of the
criteria for migration from ‘unstable’ to ‘testing’
http://www.debian.org/devel/testing>. If you want to see a newer
version of the package in Debian, those criteria are the ones you are
interested in.

The criteria, you will observe, are *not* subject to pleading for the
package to go in, nor to claims of the package's advantages. They are
much more amenable to addressing bug reports and work on the part of
the package maintainers (and those who are interested enough to help
with that work).

-- 
 \ “Here is a test to see if your mission on earth is finished. If |
  `\  you are alive, it isn't.” —Francis Bacon |
_o__)  |
Ben Finney


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

Bug#521837: ITP: ktikz -- Editor for the TikZ language

[Florian Hackenberger]

Package: wnpp
Severity: wishlist
Owner: Florian Hackenberger


* Package name: ktikz
  Version : 0.8-1
  Upstream Author : Florian Hackenberger 
* URL : 
http://www.hackenberger.at/ktikz-editor-for-the-tikz-language  
* License : GPL2 or higher   
  Programming Lang: C++ with qt4 libs.
  Description : Editor for the TikZ language
   KtikZ is a small application helping you to create TikZ (from the LaTeX
   pgf package) diagrams for your publications.

Release candidates are available from http://www.hackenberger.at/ktikz

I am not a Debian Developer, so I will need a sponsor for this package.

 



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

Re: Debian 4.0 and Lustre

[Goswin von Brederlow]

EricSingleton  writes:

> On Mar 24, 4:00 am, Andreas Tille  wrote:
>> On Tue, 24 Mar 2009, set...@gmail.com wrote:
>> > I preferDebian4.0 because I feel it is more stable than 5.0.
>>
>> Please define "more stable".
>> What are the problems which you have observed?  Did you reported these 
>> problems?
>>
>> > Am I right?
>>
>> Well, if we would *know* about this fact we probably would not have released 
>> Lenny.
>> So asking *here* whether Lenny is less stable than Etch does not sound like a
>> good strategy.
>>
>> Kind regards
>>
>>         Andreas.
>>
>> --http://fam-tille.de
>>
>> --
>> To UNSUBSCRIBE, email todebian-devel-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
> Is there any Lenny packaged with Lustre 1.6.7?

m...@book:~% rmadison lustre-source
lustre-source |  1.6.5.1-4 |stable | all
lustre-source |  1.6.5.1-4 |   testing | all
lustre-source |1.6.7-1 |  unstable | all

MfG
Goswin


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

Re: Extended descriptions size

[Goswin von Brederlow]

Andreas Tille  writes:

> On Sun, 22 Mar 2009, Michael Bramer wrote:
>
>> if we like to remove the long description from the package file, we
>> must change apt in some way and use some other rules for select the
>> right description (a new 'Description-md5sum' or the Version-Nr)
>
> I'd call the Version-Nr. a sinsible choice. ;-)
>
> Kind regards
>
>   Andreas.

I think the idea of using the Description-md5sum is that in most cases
the md5sum remains identical for many versions. If you use the
packages actual version then every upload will need a new translation
entry or some fuzzyness to accept an older versions translation.

MfG
Goswin


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

How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Goswin von Brederlow]

ftpmaster: Please comment on the last section concerning DAK behaviour.

Hi,

before Lenny ftpmaster asked us (ia32-libs maintainers) to do
something about the mess that is ia32-libs. Specifically that it is a
HUGE source duplication and a security nightmare. Unfortunaetly there
wasn't enough time before the release to get a new solution
(ia32-apt-get) into a stable state. Now that Lenny is out the problem
can be attacked again. The major remaining problems are how to
transition from ia32-libs to ia32-apt-get and how packages can depend
on 32bit libs then. (Which actualy hinge on the same problem.)


Current state: ia32-libs + ia32-libs-gtk


The ia32-libs(-gtk) source package contains precompiled i386 deb of
packages (taken from testing i386) and for each deb the respective
source package. The debian/rules file then unpacks the i386 debs,
moves some files, fixes some files and then builds the ia32-libs(-gtk)
deb out of that. This results in ~500MB source package and ~80MB
binary packages. And for every new version of any of the contained
packages there should be a new ia32-libs(-gtk) version causing a new
~600MB upload.


New solution: ia32-apt-get
--

Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow
installing deb packages from an i386 repository (or local file)
directly. The apt-get wrapper handles mangling the Packages file from
i386 during download so apt can use it and the dpkg.deb wrapper
handles converting i386 debs to amd64 / ia64 during unpacking. Through
this every i386 package in Debian (or other apt repositories) becomes
available on amd64 / ia64 as well. In case of binary/data packages the
package name remains as is while for library packages the name is
prefixed with ia32- to allow both 64bit and 32bit flavours of
libraries to be installed. Package updates become available to the
user the moment they hit the archive without needing an extra upload
or testing migration.


Transition plan
---

For obvious reasons ia32-lib* and ia32-libs(-gtk) must conflict with
each other as they contain the same libraries. They basically
represent moving a file from one package (ia32-libs) into another
(ia32-lib*). As such a "Conflicts: ia32-libs (<< 3.0~~), ia32-libs-gtk (<<
3.0~~)" and "Replaces: ia32-libs (<< 3.0~~), ia32-libs-gtk (<< 3.0~~)"
are neccessary. That should solve most packages. BUT:

Some library packages contain conffiles. How do I handle the case
of a conffile moving from ia32-libs to ia32-libfoo correctly?

Also how do I make it so that an existing ia32-libs package would pull
in the respective ia32-lib* packages on upgrades? The obvious solution
is to create ia32-libs(-gtk) meta packages that depend on the
respective ia32-lib* packages. This brings us to the main problem of
this mail:


How to depend on 32bit libs on amd64?
=

The ia32-libs(-gtk) package should look somewhat like this:

Package: ia32-libs
Version: 3.0
Depends: lib32gcc1, libc6-i386, lib32z1, lib32stdc++6, lib32asound2,
 lib32ncurses5, ia32-libattr1, ia32-libx86-1, ia32-libpam0g, ...

The problem I see here is that ia32-libattr1, ia32-libx86-1,
ia32-libpam0g, ... are not in main as far as DAK is concerned. They
are not known at all in the Debian archive. As such I think
ia32-libs(-gtk) could never transition from unstable to testing on its
own. On the users system they are also not available untill
ia32-apt-get is installed and apt-get update has been run. On a fresh
system a simple "apt-get install ia32-libs" would not be possible.

And it is not just the ia32-libs(-gtk) dummy packages that are
affected:

% apt-cache rdepends ia32-libs ia32-libs-gtk | sort -u | xargs
eagle fglrx-glx-ia32 ia32-libs-gtk ia32-sun-java5-bin
ia32-sun-java6-bin lib32asound2 lib32asound2-plugins lib32bz2-1.0
lib32ncurses5 lib32z1 libc6-i386 libwine libwine-capi libwine-cms
libwine-esd libwine-gl libwine-gphoto2 libwine-jack libwine-ldap
libwine-nas libwine-print libwine-sane nspluginwrapper nvidia-glx-ia32
nvidia-glx-legacy-71xx-ia32 nvidia-glx-legacy-96xx-ia32
teamspeak-client teamspeak-server vmware-package

Those packages should depend on the specific ia32-lib* package they
actually need instead of the ia32-libs(-gtk) meta packages. Again
creating a dependency on a seemingly non-existing package.


Does anyone have an idea how to solve this in a way that DAK remains
happy and so that e.g. "apt-get install vmware-package" will pull in
ia32-apt-get and then the right libs?

MfG
Goswin

PS: The most difficult case is nspluginwrapper. I think all other
packages could be removed from amd64 and use the i386 package
directly.


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Samuel Thibault]

Goswin von Brederlow, le Mon 30 Mar 2009 14:33:32 +0200, a écrit :
> Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow
> installing deb packages from an i386 repository (or local file)
> directly.

Mmm, couldn't there be any possible relation with the multiarch support
mentioned earlier on d-d?

Samuel


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

Re: why is Ardour pretty outdated in stable and not in testing?

[Vincent Danjean]

Grammostola Rosea wrote:
> Also maybe Debian can be a bit less conservative when such a core app is
> not in stable and stable releases go out the door after years! I guess
> some packages are added in Etch after a while.

  No (no new package, even no new version, only important (or more) bug fixes)

> But main point is, that Ardour should hit testing after a while.

  Yes, because this is the condition (required and sufficient) to allow
Ardour to be shipped in the next stable release of Debian (squeeze).


  About the current stable (lenny), all you can do is:

* provide an external repo with packages build for lenny
  => you have to compile yourself the appli for the archs you want to support
  => some users does not like to use external repo
  => there is no integration with the Debian infrastructure (PTS, BTS, ...)

* introduce a backport for lenny in the semi-official backport.org site
  => Ardour needs to be in testing to be allowed to be added here
  => some users like backport because it is nearly the same packages as
 in testing (ie official packages with, we can hope, a good quality)
  => autobuilders take care of compiling the package for other architectures
  => the BTS, PTS, qa website, ... "know" (at least a minimum) the backports
 of the packages

  Regards,
Vincent

> Kind regards,
> 
> \r
> 


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

Re: why is Ardour pretty outdated in stable and not in testing?

[Cassiel]

2009/3/30 Andreas Tille 

> On Mon, 30 Mar 2009, Fabian Greffrath wrote:
>
>  You don't seem to understand the Debian release policy. Once a stable
>> version has been released, there is zero chance that another package will be
>> added. The only chance for ardour to be part of a stable Debian release is
>> Squeeze, not Lenny.
>>
>
> There is backports.org which is a quite canonical place for people to seek
> for backports of Debian packages.  Several people do include it in their
> sources.list.  I'd prefer up to date packages there instead of "random"
> other
> locations (and yes I know that 64studio is no "random" location for
> multimedia
> experts - but obviosely there are Debian users who did not noticed it there
> ...)
>
> Kind regards
>
>  Andreas.


Ok, let's play.
Some multimedia users and experts would prefer not to use "unofficial"
debian repository and having ardour & rt kernel in the next stable release,
so now in testing.

ciao
r

Re: [GSoC] KDE4/Qt4 based package manager

[Michael Biebl]

Obey Arthur Liu wrote:
> Mateusz 'Matthew' Marek a écrit :

> 
>> That's why I think the best way to make Qt4 based package manager is
>> make it from scratch.
> Are you sure you can make a graphical package manager in one summer,
> from scratch ?
> We believe the current best approach would be to finish adept-3, with of
> course the modifications that you would like to bring in but we're open
> to any suggestions.
> 

Wasn't adept abandoned in favor of kpackagekit?
So what about getting (k)packagekit in shape on Debian instead of yet another
frontend. Maybe the time would be spent better this way.

Just my 2¢
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#521850: ITP: globus-gsi-openssl-error -- Globus Toolkit - Globus OpenSSL Error Handling

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: globus-gsi-openssl-error
* URL : http://www.globus.org/
* License : Apache-2.0
  Description : Globus Toolkit - Globus OpenSSL Error Handling

The Globus Toolkit is an open source software toolkit used for
building Grid systems and applications. It is being developed by the
Globus Alliance and many others all over the world. A growing number
of projects and companies are using the Globus Toolkit to unlock the
potential of grids for their cause.
..
This package provides functions to wrap error types defined by
OpenSSL and other tools for dealing with errors in development.



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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Adeodato Simó]

* Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:

Hello, [-mentors only Bcc'ed to drop it from the discussion]

  Executive summary: concerns about ia32-apt-get raised, lesser hack
  proposed for comments.

> before Lenny ftpmaster asked us (ia32-libs maintainers) to do
> something about the mess that is ia32-libs. Specifically that it is a
> HUGE source duplication and a security nightmare. Unfortunaetly there
> wasn't enough time before the release to get a new solution
> (ia32-apt-get) into a stable state. Now that Lenny is out the problem
> can be attacked again. The major remaining problems are how to
> transition from ia32-libs to ia32-apt-get and how packages can depend
> on 32bit libs then. (Which actualy hinge on the same problem.)

Has there been any public discussions about ia32-apt-get, and consensus
that it is an acceptable solution? To be honest, I’m not sure at all it
is actually a better solution than the 500 MB source package.

For the benefit of others, so that they can comment, I’ll mention how it
works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and
/usr/bin/dpkg-deb.

For apt-get, it intercepts the “update” operation, calling apt-get.real
first in an alternative root for the host arch (/var/lib/apt/native),
then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign),
and then doing gross sed'ing over those to morph them into acceptable
package lists for the host arch. Which are later available because the
postinst goes ahead and duplicates all entries in sources.list.

For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The latter
does all sorts of pretty things including moving files around (to
/usr/lib32, eg.), changing the Architecture field, and amending the
Depends field.

I realize quite a lot of effort has been put into writing this and to
make sure it works, but as said above, I’m unsure it’s an acceptable
solution to this problem. As an amd64 user, I’d be disgusted to see such
a hack forced down on my system, and disappointed in Debian for
sanctioning such solution.

> The problem I see here is that ia32-libattr1, ia32-libx86-1,
> ia32-libpam0g, ... are not in main as far as DAK is concerned. They
> are not known at all in the Debian archive. As such I think [packages
> depending on ia32-lib*] could never transition from unstable to
> testing on [their] own.

Actually they can, because britney can be told that some packages are
available even if they are not in the Packages lists. However, and given
my opinion above, I will refuse to do that unless there’s clear consensus 
among the active developers that this is an acceptable solution. Because
of that, opinions welcome.

I’d also be interested in hearing from ftpmaster their thoughts on the
matter. Maybe a less fugly hack can be devised if the need to address
the current ia32-libs mess is really strong.

Mark Hymers has talked about providing a mechanism to ensure source
packages stay on the pool when other stuff has been built from them (eg.
kernel module packages). With this, ia32-libs could become a small
source package containing scripts that would download the necessary
binary packages at build time, and would encode in a header the employed
versions; then, source for those versions would not be removed from the
pool.

And ia32-libs could be easily Bin-NMUed regularly, in order to pick up
the latest libraries from testing. I know downloading stuff in the build
process is not something we want to do, but we have packages with
special needs that do it by design (eg. the installer).

Thoughts? 

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: realtime kernel for Debian

[Uwe Kleine-König]

Hi Alexander,

On Mon, Mar 30, 2009 at 10:22:02AM +0200, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> Uwe Kleine-König schrieb:
> 
> > [your To: header was strange, maybe my mail reaches less recipents than
> > your's]
> 
> Well, at least it reached me ;)
> 
> >>> Maybe providing a patch package is a better first step?
> >> thanks for thinking. Who could provide such a patch package?
> > I can.  I'd need a sponsor, though.  I know two Debian developers, I
> > will ask them.
> 
> Willing to sponsor as soon as you've got a package to test ready.
Great thanks.  I plan to package rt-tests, too.  Maybe you can sponser
that, too?

Expect me to contact you via irc to go into details.

Best regards
Uwe

-- 
Pengutronix e.K.  | Uwe Kleine-König|
Industrial Linux Solutions| http://www.pengutronix.de/  |


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Peter Samuelson]

[Adeodato Simó]
> Mark Hymers has talked about providing a mechanism to ensure source
> packages stay on the pool when other stuff has been built from them (eg.
> kernel module packages). With this, ia32-libs could become a small
> source package containing scripts that would download the necessary
> binary packages at build time, and would encode in a header the employed
> versions; then, source for those versions would not be removed from the
> pool.

I understand different binary packages from a single source package do
not have to share a single version string - so could ia32-libs be done
in such a way that each binary package gets a version number related to
the "real" source package it is built from?  ia32-libs itself could
append a sort of 'micro-epoch' value that would only change when
substantive changes are made to how the binary packages are built.

Thus when you binNMU ia32-libs in order to pick up a newer library
upload, all the libraries that have not changed will not get new
version numbers and nobody would need to upgrade them.  But would this
situation (trying to upload a version that is already present) confuse
dak?  I presume dak will just ignore that binary, yes?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: Jack Audio Connection Kit transition

[Adeodato Simó]

Maintainers: unless you’re jackbeat or gst-plugins-bad0.10, you need not
upload for this, though build-depending on libjack-dev in your next
upload would be nice.

---

Hello, Felipe. I finally found some time to look at your message. I’ve
moved -release to CC (thanks for the Bcc!), since it’s on-topic there.

> Fellow developers and release team (bcc'ed),

> The Debian Multimedia Maintainers would like to drop the  versioned jack
> library and development packages (that is, libjack0.100.0-{0,dev}). They were
> introduced a long time ago (along with the appropriately renamed library) due 
> to perceived instability in the jack library's ABI. For a while now, this is 
> no longer necessary, and upstream has catalogued Debian packages of jack 
> broken because of that. The debian packages no longer change the soname of 
> the 
> library (starting with lenny), and the versioned packages are just dummy 
> ones. 
> We want to drop them now. The first thing to be done is to switch the 
> build-dependency from libjack0.100.0-dev to libjack-dev. After all packages 
> have been changed and uploaded, we can upload a jack without those 
> transitional packages (unless I overlooked something and we need the RT ack 
> first?).

> Just to be clear: there is ABI/SONAME transition here. Packages that still 
> depend on libjack0.100.0-0 use the symlink provided by that package[1]. A 
> mere "sed -i -e 's/libjack0.100.0/libjack/g' debian/control" should be all 
> that people need to do.

I assume you mean “there is NOT ABI/SONAME transition here”, heh. So,
here are my comments on the matter:

  * plan for libjack0.100.0-dev: you can make a j-a-c-k upload to
unstable dropping this development package immediately, provided
that you add a “Provides: libjack0.100.0-dev” line to the
libjack-dev package.

You will have to file two bugs at RC severity against jackbeat and
gst-plugins-bad0.10; these are the only packages that have a
*versioned* build-dependency on libjack0.100.0-dev, as far as I can
see.

I’ve also checked, and there is no pacakge with versioned
dependencies on libjack0.100.0-dev.

  * plan for libjack0.100.0-0: there are 11 source packages left with
dependencies on this old library. No sourceful uploads are needed
for this: once you’ve gotten back to me that the plan is good, I
will provide you with a list of packages and schedule Bin-NMUs; then
you can do some work of checking if they built successfully
everywhere, filing bugs, etc. Once all of them have been rebuilt
(which will make them depend on libjack0), please check with us that
they’ve migrated to testing, and at that point libjack0.100.0-0 can
be dropped.

Sounds good?

> [1] This actually surprised me. Could someone explain to me why are there 
> SONAMEs when they are not actually used? 

> % ldd /usr/bin/creox | grep jack
> libjack-0.100.0.so.0 => /usr/lib/libjack-0.100.0.so.0 
> (0x7f943206f000)
> % ls -l /usr/lib/libjack-0.100.0.so.0
> lrwxrwxrwx 1 root root 12 2009-03-18 19:03 /usr/lib/libjack-0.100.0.so.0 -> 
> libjack.so.0
> % objdump -p /usr/lib/libjack-0.100.0.so.0 | grep SONAME
>   SONAME  libjack.so.0

The SONAME that is recorded in the binary (do `objdump -p /usr/bin/creox |
grep NEEDED`, rather than ldd) is used to find the file. Once the file
is loaded, AFAIK nor the linker nor the application care what the
actuall SONAME of the loaded library is.

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Goswin von Brederlow]

Adeodato Simó  writes:

> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:
>
> Hello, [-mentors only Bcc'ed to drop it from the discussion]
>
>   Executive summary: concerns about ia32-apt-get raised, lesser hack
>   proposed for comments.
>
>> before Lenny ftpmaster asked us (ia32-libs maintainers) to do
>> something about the mess that is ia32-libs. Specifically that it is a
>> HUGE source duplication and a security nightmare. Unfortunaetly there
>> wasn't enough time before the release to get a new solution
>> (ia32-apt-get) into a stable state. Now that Lenny is out the problem
>> can be attacked again. The major remaining problems are how to
>> transition from ia32-libs to ia32-apt-get and how packages can depend
>> on 32bit libs then. (Which actualy hinge on the same problem.)
>
> Has there been any public discussions about ia32-apt-get, and consensus
> that it is an acceptable solution? To be honest, I’m not sure at all it
> is actually a better solution than the 500 MB source package.
>
> For the benefit of others, so that they can comment, I’ll mention how it
> works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and
> /usr/bin/dpkg-deb.
>
> For apt-get, it intercepts the “update” operation, calling apt-get.real
> first in an alternative root for the host arch (/var/lib/apt/native),
> then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign),
> and then doing gross sed'ing over those to morph them into acceptable
> package lists for the host arch. Which are later available because the
> postinst goes ahead and duplicates all entries in sources.list.
>
> For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The 
> latter
> does all sorts of pretty things including moving files around (to
> /usr/lib32, eg.), changing the Architecture field, and amending the
> Depends field.
>
> I realize quite a lot of effort has been put into writing this and to
> make sure it works, but as said above, I’m unsure it’s an acceptable
> solution to this problem. As an amd64 user, I’d be disgusted to see such
> a hack forced down on my system, and disappointed in Debian for
> sanctioning such solution.

The alternative solution is ia32-archive, which creates a local
repository of converted packages on the users system. No wrappers
needed and no ugly hacks but that comes at the cost of disk space and
the need to configure what packages to convert (converting just
everything would cost too much disk).

The problem how to state the depends remains the same.

>> The problem I see here is that ia32-libattr1, ia32-libx86-1,
>> ia32-libpam0g, ... are not in main as far as DAK is concerned. They
>> are not known at all in the Debian archive. As such I think [packages
>> depending on ia32-lib*] could never transition from unstable to
>> testing on [their] own.
>
> Actually they can, because britney can be told that some packages are
> available even if they are not in the Packages lists. However, and given
> my opinion above, I will refuse to do that unless there’s clear consensus 
> among the active developers that this is an acceptable solution. Because
> of that, opinions welcome.
>
> I’d also be interested in hearing from ftpmaster their thoughts on the
> matter. Maybe a less fugly hack can be devised if the need to address
> the current ia32-libs mess is really strong.
>
> Mark Hymers has talked about providing a mechanism to ensure source
> packages stay on the pool when other stuff has been built from them (eg.
> kernel module packages). With this, ia32-libs could become a small
> source package containing scripts that would download the necessary
> binary packages at build time, and would encode in a header the employed
> versions; then, source for those versions would not be removed from the
> pool.

Buildds don't have internet access in their build
environment. ia32-libs may not download anything at build time. Plus
rebuilding would give widely unreproducible results.

As for avoiding the source duplication that would be nice.

> And ia32-libs could be easily Bin-NMUed regularly, in order to pick up
> the latest libraries from testing. I know downloading stuff in the build
> process is not something we want to do, but we have packages with
> special needs that do it by design (eg. the installer).
>
> Thoughts? 

Currently the size makes regular uploads too costly imho. And the
security team is still not supporting ia32-libs. I even did prepare an
security upload for etch last year that they only had to sponsor but
never heard back from the team.

> Cheers,

MfG
Goswin


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Goswin von Brederlow]

Samuel Thibault  writes:

> Goswin von Brederlow, le Mon 30 Mar 2009 14:33:32 +0200, a écrit :
>> Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow
>> installing deb packages from an i386 repository (or local file)
>> directly.
>
> Mmm, couldn't there be any possible relation with the multiarch support
> mentioned earlier on d-d?
>
> Samuel

ia32-libs/ia32-apt-get is an ugly hack to support biarch while we wait
for multiarch.

multiarch is the clean solution for the problem.

MfG
Goswin


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Roger Leigh]

On Mon, Mar 30, 2009 at 04:26:54PM +0200, Adeodato Simó wrote:
> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:
> 
> Hello, [-mentors only Bcc'ed to drop it from the discussion]
> 
>   Executive summary: concerns about ia32-apt-get raised, lesser hack
>   proposed for comments.
> 
> > before Lenny ftpmaster asked us (ia32-libs maintainers) to do
> > something about the mess that is ia32-libs. Specifically that it is a
> > HUGE source duplication and a security nightmare. Unfortunaetly there
> > wasn't enough time before the release to get a new solution
> > (ia32-apt-get) into a stable state. Now that Lenny is out the problem
> > can be attacked again. The major remaining problems are how to
> > transition from ia32-libs to ia32-apt-get and how packages can depend
> > on 32bit libs then. (Which actualy hinge on the same problem.)
> 
> Has there been any public discussions about ia32-apt-get, and consensus
> that it is an acceptable solution? To be honest, I’m not sure at all it
> is actually a better solution than the 500 MB source package.

[...]

> I realize quite a lot of effort has been put into writing this and to
> make sure it works, but as said above, I’m unsure it’s an acceptable
> solution to this problem. As an amd64 user, I’d be disgusted to see such
> a hack forced down on my system, and disappointed in Debian for
> sanctioning such solution.

To be honest, I feel exactly the same way about it.

I'm unsure why we need *any* 32-bit libraries or binaries on an
amd64 system.  If one needs to run 32-bit software, it is possible to
debootstrap an i386 system and use it as a chroot.  Using a tool such
as schroot handles all of the kernel personality and chroot details,
and even allows normal users to use it with access to all their files,
etc.  With a few one line scripts/shell aliases, it's completely
transparent.  It also has the advantage of being a complete i386
system rather than just a collection of libraries; you can keep it up
to date using the usual tools, and even boot it if you desire.  i.e.
you get all the normal security support and updates.

With multiarch, it's a different story, but we aren't quite there yet.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Goswin von Brederlow]

Peter Samuelson  writes:

> [Adeodato Simó]
>> Mark Hymers has talked about providing a mechanism to ensure source
>> packages stay on the pool when other stuff has been built from them (eg.
>> kernel module packages). With this, ia32-libs could become a small
>> source package containing scripts that would download the necessary
>> binary packages at build time, and would encode in a header the employed
>> versions; then, source for those versions would not be removed from the
>> pool.
>
> I understand different binary packages from a single source package do
> not have to share a single version string - so could ia32-libs be done
> in such a way that each binary package gets a version number related to
> the "real" source package it is built from?  ia32-libs itself could
> append a sort of 'micro-epoch' value that would only change when
> substantive changes are made to how the binary packages are built.

Currently ia32-libs source builds one ia32-libs.deb. Not split up per
binary package it contains.

> Thus when you binNMU ia32-libs in order to pick up a newer library
> upload, all the libraries that have not changed will not get new
> version numbers and nobody would need to upgrade them.  But would this
> situation (trying to upload a version that is already present) confuse
> dak?  I presume dak will just ignore that binary, yes?

The problem isn't the really the user needing to downlod 40MB for an
update. The problem I see is having to upload 600MB and mirror
that.

And yes, uploading a new source that builds a deb with the same
version as the last source will cause DAK to reject the upload.

For your idea to work the ia32-libs source has to be split. That would
allow fine grained updates but still have the problem of source
duplication and prebuild binaries. Ftpmaster didn't want that any more
than ia32-libs now.

MfG
Goswin


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Matthew Johnson]

On Mon Mar 30 17:20, Roger Leigh wrote:
> With multiarch, it's a different story, but we aren't quite there yet.
> 
Multiarch is definitely the right way to handle this and I think we
should were possible be putting effort into that and not hacks.

I still am not clear what the holdups are with multiarch. What is there
that people like myself and the ia32-libs guys can do to get it working?

I would really like to see it in squeeze if that's possible.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: grouping of alternative depends

[Manoj Srivastava]

On Mon, Mar 30 2009, Stefano Zacchiroli wrote:

> On Sun, Mar 29, 2009 at 11:41:22AM +0100, Holger Levsen wrote:
>> I'd like to use a depends like "(pdns-backend-ldap pdns-recursor) | bind9" 
>> but 
>> afaik this is not possible. AFAICS I should file a wishbug against dpkg but 
>> as I dont have time atm to dig through all the bugs against dpkg, I thought 
>> I 
>> drop a mail here, in the hope that someone will point me to an already 
>> existing bug or if not, just submit this. TIA.
>
> The solution to this and similar problems are always, as pointed out
> by specific solutions in this thread by others, to turn your
> dependency formula into conjunctive normal form (CNF) [1], which is
> always possible, though possibly ugly, as you observed.
>
> Note that if you want to go the "wishlist bug" path however, the bug
> should not be against dpkg, but rather against policy. The reason
> being that policy currently only allows dependency formulae in
> conjunctive normal form.

And that bug on policy would have to show more reason than "I do
 not find it pretty enough" to show why we need to modify policy, and
 perhaps add complexity to code that parses the depends lines (these are
 not just dpkg and friends; our users may have wrotten scripts, as I
 have, to help satisfy dependencies while building other packages).

Unless a functional lack is demonstrated, and it can be shown
 that the functional lack actually has benefits in real life packages
 (apart from it looking prettier), I suggest the policy wishlist bug be
 thought about.

manoj
-- 
This process can check if this value is zero, and if it is, it does
something child-like.  -- Forbes Burkowski, CS 454, University of
Washington
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: This topic died off; any resolution?

[Manoj Srivastava]

On Sat, Mar 28 2009, Reinhard Tartler wrote:

> Manoj Srivastava  writes:
>
>> A special rule in debian/rules to duplicate apt-get source for
>>  people who are skeptical of thea rchive (and have an ill defined
>>  attack vector thay are being paranoid about) -- or to provide
>>  functionality that apt-get source is not a duplicate for?
>
> Well, for complicated cases (like ffmpeg, where we have to fight with
> svn:externals, external svn servers etc) it is very helpful to have such
> a rule. Espc. if some user objects with some of the modifications and
> needs to apply changes to it in order to get a slightly modified
> package.

If you are talking about cases where there is no upstream
 tarball, and just SVN (or some other VCS), and these cannot be handled
 by uscan, then I agree, it would be nice to standardize the calling
 interface. 

> I think this is a valid usecase for shipping a debian/rules target
> that mimics 'apt-get source' (which cannot know what modifications
> have been done to the source).

Well, apt-get source gets you the orig.tar.gz, and the diff.gz,
 that lets you know exactly what modifications were made to the upstream
 snapshot, so I guess I am not understanding what you are saying here.

 a) Upstream does tarballs --- use uscan, perhaps with a munging script
 b) No upstream tarball ---use a new target, or equivalently, a new
   script to do the job.

My slight preference is a script with a well known name, since
 that script can then be extracted and used by DEHS/PTS like systems,
 without requireing that the whole source be unpoacked and
 ./debian/rules be runnable (I have sanity checks in my debian/rules)

manoj
-- 
"Let us condemn to hellfire all those who disagree with us." militant
religionists everywhere
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Peter Samuelson]

[Goswin von Brederlow]
> Currently ia32-libs source builds one ia32-libs.deb. Not split up per
> binary package it contains.

Yes but I thought we were talking about changing that, so that it
builds ia32-libc6, ia32-libssl0.9.8, etc.  That is how I understood
Dato's proposal, which I think is probably the most sensible solution
I have seen so far.

> And yes, uploading a new source that builds a deb with the same
> version as the last source will cause DAK to reject the upload.

That's a problem, then.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Bug#521875: ITP: icedove-quotecolors -- Colorize different quoting levels in e-mail messages

[Christoph Goehre]

Package: wnpp
Severity: wishlist
Owner: Christoph Goehre 

* Package name: icedove-quotecolors
  Version : 0.2.8
  Upstream Author : Malte Rücker 
* URL : http://quotecolors.mozdev.org
* License : MPL
  Programming Lang: Javascript
  Description : Colorize different quoting levels in e-mail messages

With this extensions installed up to five quoting levels can be
displayed in different colors making it easier to read e-mails with lots
of quoted replies.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)


signature.asc
Description: Digital signature

Re: RFS: libnet - orphaning libnet

[David Paleino]

On Sat, 28 Mar 2009 15:12:05 +0100, David Paleino wrote:

> On Sat, 28 Mar 2009 15:22:46 +0200, Stefanos Harhalakis wrote:
> 
> > On Friday 27 March 2009, David Paleino wrote:
> > > After all, it's your choice, you should have fun working with VCS's
> > > (that's why I switched from SVN to Git most of my packages, *grin*)
> > 
> > I've retitled bug #516222 to be an ITA. I see that I need to upload a new 
> > version with myself as maintainer but since you've already a version that 
> > awaits, I'll wait for it to be uploaded first. Then I'll send another one 
> > with the changes.
> 
> Uh?
> Please go yourself, I don't have any new version ready.

Ah, sorry, I just got myself confused. Yes, you should wait someone sponsoring
the orphaned package available on mentors.debian.net, and then you can freely
start working on it :)

Sorry for not being clearer before,
David

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


signature.asc
Description: PGP signature

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Adeodato Simó]

* Goswin von Brederlow [Mon, 30 Mar 2009 18:00:08 +0200]:

> The alternative solution is ia32-archive, which creates a local
> repository of converted packages on the users system. No wrappers
> needed and no ugly hacks but that comes at the cost of disk space and
> the need to configure what packages to convert (converting just
> everything would cost too much disk).

Right, and I think that’s suboptimal from an useability POV: `apt-get
install wine` should work on amd64 out of the box, without needing to
do extra work, IMHO.

> Buildds don't have internet access in their build
> environment. ia32-libs may not download anything at build time.

I guess when you replied to this you hadn’t gotten to the part where I
said ia32-libs would be a “package with special needs”.

> Plus rebuilding would give widely unreproducible results.

Would behave the same as other packages already do (linux modules,
installer).

> Currently the size makes regular uploads too costly imho. And the
> security team is still not supporting ia32-libs. I even did prepare an
> security upload for etch last year that they only had to sponsor but
> never heard back from the team.

With my proposed hack, the upload size would be just the binary
packages, since the source would not be duplicated. Surely the Security
Team can cope with that, if they so wish. (And/or if the package would
have an arch:all package, eg. with scripts, you can get away with
uploading only that one.)

P.S.: In case it isn’t clear already, my only goal is that the hack we
may have in place while we get multiarch, is an acceptable one. I would
really like for it to be in place as little time as possible.

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


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

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Luk Claes]

Goswin von Brederlow wrote:
> Adeodato Simó  writes:
> 
>> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:

>> Mark Hymers has talked about providing a mechanism to ensure source
>> packages stay on the pool when other stuff has been built from them (eg.
>> kernel module packages). With this, ia32-libs could become a small
>> source package containing scripts that would download the necessary
>> binary packages at build time, and would encode in a header the employed
>> versions; then, source for those versions would not be removed from the
>> pool.
> 
> Buildds don't have internet access in their build
> environment. ia32-libs may not download anything at build time. Plus
> rebuilding would give widely unreproducible results.

AFAIK you're talking about 2 architectures, so building them in another
way than on the buildds should not be hard.

I guess you mean unpredictable instead of unreproducible as building
with the same versions as mentioned in the build log should be
reproducible or ia32-libs better just gets removed from the archive
altogether... Why would it be unpredictable, what issues do you see?

> Currently the size makes regular uploads too costly imho. And the
> security team is still not supporting ia32-libs. I even did prepare an
> security upload for etch last year that they only had to sponsor but
> never heard back from the team.

A good reason to not just shoot any proposal to make that easier IMHO.

Cheers

Luk


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

Bug#521893: ITP: linux-patch-preemptrt -- The CONFIG_PREEMPT_RT Patch Sets for various Debian kernels

[Uwe Kleine-König]

Package: wnpp
Severity: wishlist
Owner: "Uwe Kleine-König" 

* Package name: linux-patch-preemptrt
  Upstream Author : Ingo Molnar , Thomas Gleixner 
 and others
* URL : http://rt.wiki.kernel.org/
* License : GPL-2
  Programming Lang: C
  Description : The CONFIG_PREEMPT_RT Patch Sets for various Debian kernels

This patch allows nearly all of the kernel to be preempted, with the
exception of a few very small regions of code.

The goal of these patch sets is to guarantee an upper bound for the
system's latencies.

It's interesting e.g. for desktops doing audio processing and embedded
systems in time critical environments like automation.



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

Bug#521895: ITP: rt-tests -- Test programs for rt kernels

[Uwe Kleine-König]

Package: wnpp
Severity: wishlist
Owner: "Uwe Kleine-König" 

* Package name: rt-tests
  Version : 0.33
  Upstream Author : Clark Williams , Thomas Gleixner 
 and others
* URL : 
http://git.kernel.org/?p=linux/kernel/git/clrkwllms/rt-tests.git
* License : GPL-2
  Programming Lang: C
  Description : Test programs for rt kernels

rt-tests contains a set of programs that test and measure various
components of "realtime" kernel behavior, such as timer latency, signal
latency and the functioning of priority-inheritance mutexes.



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

Re: This topic died off; any resolution?

[Reinhard Tartler]

Manoj Srivastava  writes:
>> Well, for complicated cases (like ffmpeg, where we have to fight with
>> svn:externals, external svn servers etc) it is very helpful to have such
>> a rule. Espc. if some user objects with some of the modifications and
>> needs to apply changes to it in order to get a slightly modified
>> package.
>
> If you are talking about cases where there is no upstream
>  tarball, and just SVN (or some other VCS), and these cannot be handled
>  by uscan, then I agree, it would be nice to standardize the calling
>  interface.

Yes, I'm talking about excatly this kind of upstream.

>> I think this is a valid usecase for shipping a debian/rules target
>> that mimics 'apt-get source' (which cannot know what modifications
>> have been done to the source).
>
> Well, apt-get source gets you the orig.tar.gz, and the diff.gz,
>  that lets you know exactly what modifications were made to the upstream
>  snapshot, so I guess I am not understanding what you are saying here.
>
>  a) Upstream does tarballs --- use uscan, perhaps with a munging script
>  b) No upstream tarball ---use a new target, or equivalently, a new
>script to do the job.

Oh, I've been using debian/get-orig-source.sh so far (which is called by
the rule 'get-orig-source' in debian/rules). If the script should have
another name, feel free to propose one.

> My slight preference is a script with a well known name, since
>  that script can then be extracted and used by DEHS/PTS like systems,
>  without requireing that the whole source be unpoacked and
>  ./debian/rules be runnable (I have sanity checks in my debian/rules)

I think you have a very good point: Until now we have a single target
("get-orig-source") for both semantics. How about proposing names for
two new (optional) scripts with better defined semantics? Ideally one of
the two is very similar (if not exactly) to the current get-orig-source
rule in debian/rules, so that the rule can be replaced to a call of that
script. Ideally it can just call uscan with a proper munging script.

-- 
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

Re: Re: [GSoC] KDE4/Qt4 based package manager

[Filipus Klutiero]

Christian Perrier wrote:

Quoting Obey Arthur Liu (art...@milliways.fr):

> > synaptic or shaman (from Chakra). I think that aptitude-gtk and adept
> > are not userfriendly. Using these applications was quite difficult for
> Heartfelt thank yous! (I'm the guy responsible for aptitude-gtk.. :D )


Is this silly to think that, as most of the (good) work was made in
aptitude-gtk, an aptitude-qt development would be a better idea?
At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI 
for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But 
Aptitude is an APT front-end. Which means aptitude-qt would be a 
front-end to a front-end. We only want a Qt/KDE APT front-end.


aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk. 
It's only experimental, but it not only depends on aptitude, it's also 
part of the aptitude source package. I'm not convinced that an 
aptitude-qt would do much better.



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

Re: [GSoC] KDE4/Qt4 based package manager

[Obey Arthur Liu]

Filipus Klutiero a écrit :

> Christian Perrier wrote:
>> Is this silly to think that, as most of the (good) work was made in
>> aptitude-gtk, an aptitude-qt development would be a better idea?

> At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI
> for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But
> Aptitude is an APT front-end. Which means aptitude-qt would be a
> front-end to a front-end. We only want a Qt/KDE APT front-end.

To be exact, "aptitude-gtk" is as much a "front-end" of "aptitude" as
the ncurse version of aptitude is, or the console version for that
matter, is a "front-end" of "aptitude".

Aptitude is much more than a bare APT front-end. It embarks its own
elaborate resolver and quite a few other things.

Also, aptitude-gtk is not just making calls to the aptitude binary or
libraries or whatever, it's an integral part of the code.

> aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk.
> It's only experimental, but it not only depends on aptitude, it's also
> part of the aptitude source package. I'm not convinced that an
> aptitude-qt would do much better.

Aptitude-gtk is aptitude and aptitude is aptitude-gtk... The "aptitude"
package in experimental is actually "aptitude-gtk" with the -gtk parts
turned off at build-time.

As to the fact that some don't like the aptitude UI paradigm, well,
that's one of the reasons I'm pushing for an alternative package manager
with Adept, for those who prefer a more task-based UI.

I hope I clarified a few points.

Arthur

-- 
Obey Arthur Liu




signature.asc
Description: OpenPGP digital signature

Re: Extended descriptions size

[Michael Bramer]

Goswin von Brederlow schrieb:

Andreas Tille  writes:


On Sun, 22 Mar 2009, Michael Bramer wrote:


if we like to remove the long description from the package file, we
must change apt in some way and use some other rules for select the
right description (a new 'Description-md5sum' or the Version-Nr)

I'd call the Version-Nr. a sinsible choice. ;-)

Kind regards

  Andreas.


I think the idea of using the Description-md5sum is that in most cases
the md5sum remains identical for many versions. If you use the
packages actual version then every upload will need a new translation
entry or some fuzzyness to accept an older versions translation.


ACK

Gruss
Grisu


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

Re: Extended descriptions size

[Andreas Tille]

On Mon, 30 Mar 2009, Michael Bramer wrote:


Goswin von Brederlow schrieb:

I think the idea of using the Description-md5sum is that in most cases
the md5sum remains identical for many versions. If you use the
packages actual version then every upload will need a new translation
entry or some fuzzyness to accept an older versions translation.


I understood the sense of having md5sums in translation files. My
suggsetion was an *additional* field which keeps the package version.
In case there are different versions of a package in one dist (might
be because an arch is lagging behind) either the md5sums differ
and you store different translations anyway or the desciptions are
equal and in this case use the highes available version number.

Kind regards

   Andreas.
--
http://fam-tille.de


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

Re: [GSoC] KDE4/Qt4 based package manager

[Sune Vuorela]

On 2009-03-29, Mateusz 'Matthew' Marek  wrote:
> Hi,
>
> I would be interested in making KDE4/Qt4 based package manager. I am
> 2nd year student of computer science from Poland (Gdansk University of
> Technology, CET/CEST) with some experience in C/C++ and Qt programming
> and git as SCM. Currently during my spare time I am working on light
> music player in Qt4.5 for Linux (something like foobar2000 for
> Windows). I think that it will be possible for me to do that package
> manager, if I take some time during the community bounding period to
> learn more about Debian package system and reserve my vacation and end
> of  time to my vacation and main application.
>
> I think that it will be good idea to make this application only in Qt
> (without KDE4). Thanks to that someone who doesn't use KDE could use
> this package manager without downloading extra dependeces.
> How this package manager should look? I would make it look a bit like
> synaptic or shaman (from Chakra). I think that aptitude-gtk and adept
> are not userfriendly. Using these applications was quite difficult for
> me. This kind of program is aimed at beginners, so we must make
> everything to try make package installing with this tool as simple as
> possible.
> That's why I think the best way to make Qt4 based package manager is
> make it from scratch.
>
> If you have any questions, just send me an email. I have problem with
> writing in English, but I hope that content of this email is clear for
> you.

As being the one who suggested this project, I guess I should answer as
well.
I guess I will start with the "bad things" in your mail and then go on
from there.

I don't think a package manager frontend should be "aimed at beginners", 
if that means that you by design not can get to any advanced features
thru the interface. But what do you mean by "user friendly"?  "beginner
friendly"? "not friendly to the power user"?

I don't think that "making a package manager from scratch" is the right
way to do either, at least if that involves writing resolver engines and
such.
Note that synaptic, aptitude-gtk and adept all uses libraries
for dependency resolving. Starting from "adept" will give you a working
interface to libapt.

Adept also uses apt-xapian-index for some of the searching which might
or might not complicate things for you as a user.

I do also think that aptitude-gtk and adept have a fairly different way
of doing things, so putting them in the same "not userfriendly" bucket
can't be right.

enough of the bad sides.

Doing it with Qt libs and without kdelibs is fully possible and I will
not recommend either of the ways, because both ways are fully valid.

And thank you for looking into a kde4/qt4 based package manager, it is
really needed. 

Starting from adept gives you nice interaction with apt and a search
possibilities thru apt-xapian-index, and then you have the possibilities
to muffle the userinterface around to actually make it fit better into
what's good for package management and also choices about wether how
detailed information about the progress of the equivalent of "apt-get
update" should be.
I do also think adept has its shortcomings, especially between the
"search" and "details" tab, but I do like that it is based on debtags
rather than archive sections, the latter being something that should go
away.

But there is more into it than the user interface.

Adept is missing signature verification, I think.
Adept is missing sources.list editor.

I mostly think adept is the way to start from because it is actually
kind of working and you don't have to start from scratch.

and some real nice things might be policykit-integration, integration
with kde for proxy-information and such.

/sune


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

Developing aptitude frontends (was Re: [GSoC] KDE4/Qt4 based package manager)

[Filipus Klutiero]

Obey Arthur Liu wrote:

Filipus Klutiero a écrit :

> Christian Perrier wrote:
>> Is this silly to think that, as most of the (good) work was made in
>> aptitude-gtk, an aptitude-qt development would be a better idea?

> At first sight, it does sound silly to me. aptitude-gtk is a GTK+ GUI
> for Aptitude. Similarly, aptitude-qt would be a Qt UI for Aptitude. But
> Aptitude is an APT front-end. Which means aptitude-qt would be a
> front-end to a front-end. We only want a Qt/KDE APT front-end.

To be exact, "aptitude-gtk" is as much a "front-end" of "aptitude" as
the ncurse version of aptitude is, or the console version for that
matter, is a "front-end" of "aptitude".
  

Well, the description of the 2008 GSoC aptitude project states:

I will create a GTK+ GUI for Aptitude [...]




Aptitude is much more than a bare APT front-end. It embarks its own
elaborate resolver and quite a few other things.
  
I agree that aptitude may have done more than it was supposed to in the 
past, but the current situation is better, and I seem to hear it's still 
improving. I'm not an aptitude user; these things may be good or not, 
but even if they're good, I think the factorization should continue 
rather than mangling things even more.

Also, aptitude-gtk is not just making calls to the aptitude binary or
libraries or whatever, it's an integral part of the code.

> aptitude-foo was tried in last summer's GSoC, resulting in aptitude-gtk.
> It's only experimental, but it not only depends on aptitude, it's also
> part of the aptitude source package. I'm not convinced that an
> aptitude-qt would do much better.

Aptitude-gtk is aptitude and aptitude is aptitude-gtk... The "aptitude"
package in experimental is actually "aptitude-gtk" with the -gtk parts
turned off at build-time.
According to aptitude's extended description, "aptitude is a 
terminal-based package manager". I'm far from being an aptitude expert, 
but my point is not terminological. I'm just saying that writing 
front-ends to a front-end is probably not the best way to go. If 
aptitude is as you say still much more than an APT front-end, this may 
be an issue worth considering before expanding it (or writing new 
software that depends on it, depending on the terminology).



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

Re: This topic died off; any resolution?

[Russ Allbery]

Manoj Srivastava  writes:

> My slight preference is a script with a well known name, since
>  that script can then be extracted and used by DEHS/PTS like systems,
>  without requireing that the whole source be unpoacked and
>  ./debian/rules be runnable (I have sanity checks in my debian/rules)

A (minor) problem with an external script is that dpkg-source won't make
it executable, so you have to make it executable before running it (or
assume what language it's written in, which seems like a bad move).

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


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

Re: Jack Audio Connection Kit transition

[Felipe Sateler]

On Tue, Mar 31, 2009 at 02:19, Adeodato Simó  wrote:
> Maintainers: unless you’re jackbeat or gst-plugins-bad0.10, you need not
> upload for this, though build-depending on libjack-dev in your next
> upload would be nice.
>
> ---
>
> Hello, Felipe. I finally found some time to look at your message. I’ve
> moved -release to CC (thanks for the Bcc!), since it’s on-topic there.
>
>> Fellow developers and release team (bcc'ed),
>
>> The Debian Multimedia Maintainers would like to drop the  versioned jack
>> library and development packages (that is, libjack0.100.0-{0,dev}). They were
>> introduced a long time ago (along with the appropriately renamed library) due
>> to perceived instability in the jack library's ABI. For a while now, this is
>> no longer necessary, and upstream has catalogued Debian packages of jack
>> broken because of that. The debian packages no longer change the soname of 
>> the
>> library (starting with lenny), and the versioned packages are just dummy 
>> ones.
>> We want to drop them now. The first thing to be done is to switch the
>> build-dependency from libjack0.100.0-dev to libjack-dev. After all packages
>> have been changed and uploaded, we can upload a jack without those
>> transitional packages (unless I overlooked something and we need the RT ack
>> first?).
>
>> Just to be clear: there is ABI/SONAME transition here. Packages that still
>> depend on libjack0.100.0-0 use the symlink provided by that package[1]. A
>> mere "sed -i -e 's/libjack0.100.0/libjack/g' debian/control" should be all
>> that people need to do.
>
> I assume you mean “there is NOT ABI/SONAME transition here”, heh.

Indeed.

> So,
> here are my comments on the matter:
>
>  * plan for libjack0.100.0-dev: you can make a j-a-c-k upload to
>    unstable dropping this development package immediately, provided
>    that you add a “Provides: libjack0.100.0-dev” line to the
>    libjack-dev package.

Sounds like a better plan.

>
>    You will have to file two bugs at RC severity against jackbeat and
>    gst-plugins-bad0.10; these are the only packages that have a
>    *versioned* build-dependency on libjack0.100.0-dev, as far as I can
>    see.
>
>    I’ve also checked, and there is no pacakge with versioned
>    dependencies on libjack0.100.0-dev.

OK.

>
>  * plan for libjack0.100.0-0: there are 11 source packages left with
>    dependencies on this old library. No sourceful uploads are needed
>    for this: once you’ve gotten back to me that the plan is good, I
>    will provide you with a list of packages and schedule Bin-NMUs; then
>    you can do some work of checking if they built successfully
>    everywhere, filing bugs, etc. Once all of them have been rebuilt
>    (which will make them depend on libjack0), please check with us that
>    they’ve migrated to testing, and at that point libjack0.100.0-0 can
>    be dropped.
>
> Sounds good?

Amsynth will require a sourceful upload, since the dependency is not
generated by dpkg-shlibdeps because it dlopens libjack. It is the only
one I saw.


Saludos,
Felipe Sateler


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

Re: This topic died off; any resolution?

[Manoj Srivastava]

On Mon, Mar 30 2009, Russ Allbery wrote:

> Manoj Srivastava  writes:
>
>> My slight preference is a script with a well known name, since
>>  that script can then be extracted and used by DEHS/PTS like systems,
>>  without requireing that the whole source be unpoacked and
>>  ./debian/rules be runnable (I have sanity checks in my debian/rules)
>
> A (minor) problem with an external script is that dpkg-source won't make
> it executable, so you have to make it executable before running it (or
> assume what language it's written in, which seems like a bad move).

Well, programs that extract these files can do so. But the thing
 is, we can now make get-orig-source actually work with these external
 script too:

--8<---cut here---start->8---
GET_SRC_VERSION  := $(strip $(shell LC_ALL=C dpkg-parsechangelog | \
   egrep '^Version:' | cut -f 2 -d ' '))
get-orig-source: get-latest-source

get-latest-source:
test ! -f debian/getsrc || test ! -x debian/getsrc || \
   chmod +x debian/getsrc
test ! -f debian/getsrc || ./debian/getsrc

get-debian-source:
test ! -f debian/getsrc || test ! -x debian/getsrc || \
   chmod +x debian/getsrc
test ! -f debian/getsrc || \
 ./debian/getsrc --upstream-version $GET_SRC_VERSION
--8<---cut here---end--->8---

./debian/getsrc can then be "exec uscan $@", or something else.
 We can have snippets setting GET_SRC_VERSION to what debian/changelog
 has, or something else.

This is the best of both worlds, no? we have a common make
 target, and we have a simply named script, that can be extracted.

manoj
-- 
Democracy is a device that insures we shall be governed no better than
we deserve.  -- George Bernard Shaw
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: This topic died off; any resolution?

[Russ Allbery]

Manoj Srivastava  writes:

> Well, programs that extract these files can do so. But the thing
>  is, we can now make get-orig-source actually work with these external
>  script too:
>
> --8<---cut here---start->8---
> GET_SRC_VERSION  := $(strip $(shell LC_ALL=C dpkg-parsechangelog | \
>egrep '^Version:' | cut -f 2 -d ' '))
> get-orig-source: get-latest-source
>
> get-latest-source:
> test ! -f debian/getsrc || test ! -x debian/getsrc || \
>chmod +x debian/getsrc
> test ! -f debian/getsrc || ./debian/getsrc
>
> get-debian-source:
> test ! -f debian/getsrc || test ! -x debian/getsrc || \
>chmod +x debian/getsrc
> test ! -f debian/getsrc || \
>  ./debian/getsrc --upstream-version $GET_SRC_VERSION
> --8<---cut here---end--->8---
>
> ./debian/getsrc can then be "exec uscan $@", or something else.
>  We can have snippets setting GET_SRC_VERSION to what debian/changelog
>  has, or something else.
>
> This is the best of both worlds, no? we have a common make
>  target, and we have a simply named script, that can be extracted.

At the cost of additional complexity of the specification, which I'm not
really happy about.  I'd rather standardize one single interface, not
require both interfaces be available with boilerplate glue.  Also, on a
similar complexity front, I'd rather decide which of the two
get-orig-source should be and not standardize both unless people see a
real need to have both of them).

-- 
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

Bug#521978: ITP: armadillo -- streamlined C++ linear algebra library

[Kumar Appaiah]

Package: wnpp
Severity: wishlist
Owner: Kumar Appaiah 

  Package name   : armadillo
  Version: 0.6.2
  Upstream Author: Conrad Anderson (conradsand at ieee.org)
  URL: http://arma.sf.net
  License: Dual Licensed, GPL-3+ and LGPL-3+
  Programming Lang   : C++

Description: streamlined C++ linear algebra library
 Armadillo is a streamlined C++ linear algebra library (matrix maths)
 aiming towards a good balance between speed and ease of use. Integer,
 floating point and complex numbers are supported, as well as a subset
 of trigonometric and statistics functions. Optional integration with
 LAPACK and ATLAS libraries is also provided.

Extras: Reason for request for inclusion in Debian: The reason why I
think this package should be in Debian is because it is (to my
knowledge) among the only few libraries which support delayed
evaluation to improve computational efficiency. I believe that several
users who need scientific computation may derive benefit from this.

Another point of note is that, though it does seem to be the case that
this library provides similar functionality to IT++ (libitpp), they
actually compliment each other with non-overlapping feature sets, and
Armadillo can be used along with IT++.

Maintenance: I propose to include this package with the Debian Science
Team as maintainer, since co-maintaining is much more reliable when
I (as an individual) am not as responsive as I ought to be...

Comments and suggestions welcome.

Thanks.

Kumar
-- 
Kumar Appaiah


signature.asc
Description: Digital signature

Bug#522006: ITP: libtest-most-perl -- Perl module with the most commonly needed test functions and features

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov 

* Package name: libtest-most-perl
  Version : 0.21
  Upstream Author : Curtis "Ovid" Poe 
* URL : http://search.cpan.org/dist/Test-Most/
* License : same as Perl (GPL-1+|Artistic)
  Programming Lang: Perl
  Description : Perl module with the most commonly needed test functions 
and features

  Test::Most provides the most commonly used testing functions and gives
  a bit more fine-grained control over your test suite.
  .
  All functions from the following modules will automatically be
  exported:
  .
   * Test::More
   * Test::Exception
   * Test::Differences
   * Test::Deep
   * Test::Warn
  .
  This is useful when one is used to most of the above moodules but
  wouldn't want to bother to load them all explicitly.
  .
  Test::Most also provides a couple of routines to control tests
  behaviour in case of errors.

This module is required for building padre 0.32 and will be maintained
by the debian perl group.



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

Re: This topic died off; any resolution?

[Manoj Srivastava]

On Mon, Mar 30 2009, Russ Allbery wrote:

> Manoj Srivastava  writes:
>
>> get-orig-source: get-latest-source
>> get-latest-source:
>> get-debian-source:

> At the cost of additional complexity of the specification, which I'm not
> really happy about.  I'd rather standardize one single interface, not
> require both interfaces be available with boilerplate glue.  Also, on a
> similar complexity front, I'd rather decide which of the two
> get-orig-source should be and not standardize both unless people see a
> real need to have both of them).

Assuming you are referring to downloading the latest versus
 current versus specified upstream version
  a) We can always get current and any previous version of the modified
 source from the debian archive using apt-get source, so it is less
 critical to have that codified as a rules target
  b) The latest sources, especially mangled, are not downloadable, and
 need help
  c) The current wording, and the default of uscan,  both talk about the
 latest upstream, 
  d) Even from a VCS, getting HEAD is usually  easy; getting a specific
 version requires knowledge of how such snapshots are recorded
 (tags, etc). This is specially true for VCS's that allow sub
 modules, like arch, and git.
  e) We can also see if people adopt get-upstream-source as a target
 that gets a specified version from upstream before making it
 policy. 


Since current policy language is about latest sources, it is
 less of a shift to add clarity without changing the default, and we can
 always let people create a new target for getting  a specified upstream
 version, and let the design for specifying the upstream version to get
 be developed in the wild, and not do the design work in policy.


manoj
-- 
Nothing recedes like success. Walter Winchell
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: This topic died off; any resolution?

[Raphael Hertzog]

On Mon, 30 Mar 2009, Russ Allbery wrote:
> Manoj Srivastava  writes:
> 
> > My slight preference is a script with a well known name, since
> >  that script can then be extracted and used by DEHS/PTS like systems,
> >  without requireing that the whole source be unpoacked and
> >  ./debian/rules be runnable (I have sanity checks in my debian/rules)
> 
> A (minor) problem with an external script is that dpkg-source won't make
> it executable, so you have to make it executable before running it (or
> assume what language it's written in, which seems like a bad move).

A problem which is also solved with format 3.0 (quilt) since the debian
files are now stored in a tarball.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

[Soeren Sonnenburg]

Package: wnpp
Severity: wishlist
Owner: Soeren Sonnenburg 

* Package name: jblas
  Version : 0.1
  Upstream Author : Mikio Braun mikiocs.tu-berlin.de
* URL : https://ml01.zrz.tu-berlin.de/trac/jblas/
* License : BSD
  Programming Lang: Java
  Description : jblas is a fast linear algebra library for Java

  jblas is a fast linear algebra library for Java. jblas is based on
  BLAS and LAPACK, the de-facto industry standard for matrix
  computations, and uses state-of-the-art implementations like ATLAS for
  all its computational routines, making jBLAS very fast. 

  jblas can is essentially a light-wight wrapper around the BLAS and
  LAPACK routines. These packages have originated in the Fortran
  community which explains their archaic API. On the other hand modern
  implementations are hard to beat performance wise. jblas aims to make
  this functionality available to Java programmers such that they do not
  have to worry about writing JNI interfaces and calling conventions of
  Fortran code.

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (i686)



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