Re: question about iptables and bug #538608

[Raphael Hertzog]

Hi,

On Wed, 29 Jul 2009, Jérémy Lal wrote:
> the "renamed debian/patches to debian/patch to avoid
> 3.0-quilt-by-default bug reports"
> changelog in latest iptables makes me uncomfortable...
> is it something we should all do eventually ?

Definitely no.

Some maintainers with complex build system might want to handle patches
separately and not let dpkg-source handle it, in that case it can make
sense.

But in most cases, one should simply adapt the build system to be
compatible with the new source format 3.0 (quilt). It usually doesn't
involve many changes.

In the case of iptables, I really don't think it was warranted to work
around in that way but since it's up to the maintainer... 

Cheers,
-- 
Raphaël Hertzog


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

Re: Bug#539008: ITP: telepathy-qt4 -- Telepathy framework - Qt 4 library

[Modestas Vainius]

Hello,

> I'd prefer to maintain it in pkg-telepathy rather than as a Qt/KDE package,
> since I don't actually use KDE myself (don't panic, the other maintainers
> do!), and the pkg-telepathy team works very closely with Telepathy upstream
> due to being basically the same people :-)

Those two are maintained by Debian Krap Maintainers because they used to be 
needed by KDE. Sure, it is the same team as Debian Qt/KDE, but most of those 
packages are free (and welcome) to be taken care of by other people who 
know/care more about the software in question. So you are very welcome to 
package telepathy-qt4 and later file bugs reports against old packages if you 
want us to ask for their removal.

-- 
Modestas Vainius 


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

Re: question about iptables and bug #538608

[Francesco P. Lovergine]

On Wed, Jul 29, 2009 at 10:27:20AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 29 Jul 2009, Jérémy Lal wrote:
> > the "renamed debian/patches to debian/patch to avoid
> > 3.0-quilt-by-default bug reports"
> > changelog in latest iptables makes me uncomfortable...
> > is it something we should all do eventually ?
> 
> Definitely no.
> 
> Some maintainers with complex build system might want to handle patches
> separately and not let dpkg-source handle it, in that case it can make
> sense.
> 
> But in most cases, one should simply adapt the build system to be
> compatible with the new source format 3.0 (quilt). It usually doesn't
> involve many changes.
> 
> In the case of iptables, I really don't think it was warranted to work
> around in that way but since it's up to the maintainer... 
> 
> Cheers,

At least in one case, I change the series file on-fly at building time
to create different flavors of the same lib with a different patchset. 
I roughly suspect this is not compatible with the 3.0 format, but it 
is also difficult to be auto-detected...

-- 
Francesco P. Lovergine


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

Re: dash pulled on stable when APT::Default-Release is used

[Felix Zielcke]

Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean:
> Hi,
> 
>   Since a few days, on a stable machine (with stable, testing and
> unstable sources for apt but APT::Default-Release set to "stable"),
> "apt-get dist-upgrade" wants to install dash.
>   Can someone explain me why ? Is it due to the fact that dash is
> essential in unstable ?

I assume it is. 
I thought I read somewhere that the reason why bash started to depend on
dash would be that apt doestn't pull in new essential packages. Though
on IRC I was told it does that already for a long time.

So if you don't want dash installed to be on a system which mainly uses
stable you have to remove unstable from sources.list

But I think dash doestn't hurt, it's small and I use it as /bin/sh since
a year or so without problems.


-- 
Felix Zielcke
Proud Debian Maintainer


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

Re: Please test eglibc 2.9-23+multiarch

[Sven Joachim]

On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:

> I have recently uploaded to experimental eglibc 2.9-23+multiarch, from 
> our multiarch branch. It doesn't use the multiarch paths yet, but it is
> a first step toward multiarch. 
>
> The only difference with the unstable version is that libc-bin and
> libc-dev-bin are splitted out of libc6 and libc6-dev. This way it
> complies with the Debian Policy requirement that the libraries should 
> not contain binaries, which is also a requirement for multiarch.
>
> Please test it and report possible problems related to this package
> split. If no problem are detected, it will be uploaded to unstable as
> soon as the current version migrates to testing. This way it will leave
> space in experimental for eglibc 2.10.
>
> Note that it is currently not yet available on all architectures, please
> wait for the experimental buildds to do their jobs.

I was not patient enough for that and built the packages myself instead
on i386.  The result is not quite satisfactory, in a Lenny chroot they
cannot be installed due to a dependency cycle:

,
| # cat /etc/debian_version 
| 5.0.2
| turtle:/# LANG=C apt-get dist-upgrade
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Calculating upgrade... Done
| The following NEW packages will be installed:
|   libc-bin
| The following packages will be upgraded:
|   libc6 libc6-dev locales
| 3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
| Need to get 0B/13.9MB of archives.
| After this operation, 6042kB of additional disk space will be used.
| Do you want to continue [Y/n]? 
| WARNING: The following packages cannot be authenticated!
|   libc6-dev locales libc6 libc-bin
| Install these packages without verification [y/N]? y
| E: Couldn't configure pre-depend libc-bin for libc6, probably a dependency 
cycle.
`

Same problem with aptitude, and this is the reason: libc6
2.9-23+multiarch Pre-Depends on libc-bin (= 2.9-23+multiarch) which in
turn Depends on libc6 (>> 2.9), so if you didn't have libc6 2.9-x
already installed, you're hosed.

Sven


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

Automatic Debug Packages

[Emilio Pozuelo Monfort]

Hi folks,

I proposed [1] a GSoC project this spring which was accepted, and I'm thus
working on getting automatic debug packages into Debian.

The reasons for this are, among others, that adding -dbg packages to thousands
of packages doesn't scale, that they bloat the archive and mirrors, and the
ability to use debugging symbols over the network by using build-ids.

The proposal is (very briefly) to make dak accept .ddeb packages (containing
debugging symbols using build-ids), and to then modify helper tools to
automatically generate them and add them to the changes file. I've written down
the details in the wiki [2], and I'll appreciate it if you could give some
feeback. I don't want to trash this completely though, so no drastic changes
preferred :)

Cheers,
Emilio

[1] http://lists.debian.org/debian-devel/2009/04/msg00421.html
[2] http://wiki.debian.org/AutomaticDebugPackages



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Paul Wise]

I note that you plan to modify the helper tools
(debhelper/cdbs/yada/etc). I think that you will get better coverage
by modifying dpkg-dev instead. Have you not considered that option or
am I missing a disadvantage of it?

Thanks for working on this, it is really great to see it happening finally.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Please test eglibc 2.9-23+multiarch

[Aurelien Jarno]

On Wed, Jul 29, 2009 at 03:52:28AM +0200, Aurelien Jarno wrote:
> On Wed, Jul 29, 2009 at 12:28:30AM +0200, Vincent Danjean wrote:
> >   Hi,
> > 
> > Aurelien Jarno wrote:
> > > The only difference with the unstable version is that libc-bin and
> > > libc-dev-bin are splitted out of libc6 and libc6-dev. This way it
> > > complies with the Debian Policy requirement that the libraries should 
> > > not contain binaries, which is also a requirement for multiarch.
> > 
> > I just tried to upgrade libc6 with experimental. The upgrade has been
> > smooth but libc-dev-bin has not been pulled in (whereas libc6-dev has been
> > upgraded). Is it the expected behavior ?
> > 
> 
> Thanks for noticing that. It's not normal that libc-dev-bin is not
> pulled, but if you look at the dependencies it actually normal.
> 
> I'll try to understand why the dependency is declared in the
> debian/control file, but does not appear is in the final binary. Stay
> tuned.
> 

I have just found, the problem, it will be fixed in the next upload.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Automatic Debug Packages

[Michael Banck]

On Wed, Jul 29, 2009 at 03:14:06PM +0200, Paul Wise wrote:
> I note that you plan to modify the helper tools
> (debhelper/cdbs/yada/etc). I think that you will get better coverage
> by modifying dpkg-dev instead. Have you not considered that option or
> am I missing a disadvantage of it?

AFAIK, dpkg-dev is only invoked at source-unpack and package-build time,
i.e. you need a full DEBIAN/ directory for dpkg-dev to act on.

At that time, either you have thrown away the debugging information
already (via dh_strip, e.g.), or not.

This is all AIUI.


Michael


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

Re: Automatic Debug Packages

[Cyril Brulebois]

Michael Banck  (29/07/2009):
> At that time, either you have thrown away the debugging information
> already (via dh_strip, e.g.), or not.
> 
> This is all AIUI.

There are some environment variables set by dpkg-buildpackage already, I
guess debhelper stuff could be set accordingly. Meh. :)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Paul Wise]

On Wed, Jul 29, 2009 at 3:29 PM, Michael Banck wrote:

> AFAIK, dpkg-dev is only invoked at source-unpack and package-build time,
> i.e. you need a full DEBIAN/ directory for dpkg-dev to act on.
>
> At that time, either you have thrown away the debugging information
> already (via dh_strip, e.g.), or not.

I was thinking DEB_BUILD_OPTIONS=nostrip would be set by dpkg-buildpackage.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Hi,

I got some good feedback from my previous Introduction to multiarch
post and some good questions. I'm singling out Manoj Srivastava here
because he was the most recent to ask this on irc but there where
others with the same or simmilar question.

The full multiarch proposal can be read on:
  https://wiki.ubuntu.com/MultiarchSpec

Manoj as maintainer wondered what, in a few words, would be involved
in migrating his packages to multiarch. I will use amd64 as example
case but any other multiarch combination works just the same.  It
turns out it is more than a few words to spell it all out, on irc is
was just 3 lines. But half the mail are 2 two example patches. So here
we go:


Introduction to multiarch: What maintainers must do
===

To begin with there are 5 cases to consider: (in order of complexity)

1) Architecture: all package
2) Binary package
3) Library package
4) Script interpreter or Service with plugins (and their plugins)
5) none of the above (or I don't care)

For each deb build by your source package you have to decide which of
the 5 cases applies individually. Note that option 5 is safe. You
might hold us all back but you won't break anything.


1) Architecture: all package


You have won. Your package is already multiarch. Hurray.
Now wasn't that easy?


2) Binary package
-

Binary package here means that you package some tool that resides in
[/usr]/[s]bin. For example /bin/sed. Now it does not matter wether sed
is 32bit or 64bit. It also doesn't matter if the program calling sed
is 32bit or 64bit. Now all you need to do is tell dpkg/apt that. You
simply add

  Multi-Arch: foreign

in the debian/control stanza for that package and you are done.
Still easy.


3) Library package
--

Library packages are slightly more complex, meaning you do have to do
some actual work. Library package mean that you have some shared
library in [/usr]/lib. For example /usr/lib/libz.so.1.2.3.3. Now it
matters wether the library is 32bit or 64bit. Only 32bit binaries can
use the 32bit library and only 64bit binaries can use the 64bit
library. If the user wants to install a 64bit perl but a 32bit mplayer
he will need both the 64bit and 32bit libz.so.1.2.3.3 installed. For
that you need to do 3 things:

  a) Follow Policy 8.2 (MUST directive)
 No conffiles, no binaries in the library package, no shared files
 (/usr/share/doc/package/ is excempt and dpkg will handle that).
 Many packages do that already and you should have been doing that
 all along.

  b) Move the libraries to multiarch dirs
 To prevent overwrite conflicts in dpkg the libraries on each
 architecture must be in a unique location, namely
 [/usr]/lib/$(DEB_HOST_GNU_TYPE). If you do have library support
 files then they have to be made not unique as well, e.g. go into
 /usr/lib/$(DEB_HOST_GNU_TYPE)/package/.
 For most sources that means running
   ./configure --libdir=/usr/lib/$(DEB_HOST_GNU_TYPE)
 or whatever your build system uses to set the library location.
 The debian/package.install filles might need to be adjusted to
 the new location to or locations used in the rules file itself.

  c) Add Multiarch: same

There, that wasn't so bad, was it?


4) Script interpreter or Service with plugins
-

This is the big scary monster and can't be done in the first round as
it needs some modifications to dpkg to go into a stable release
first. The problem here is that for python scripts it does not matter
wether you have a 32bit or 64bit python. But the 32bit python gtk
bindings only work with a 32bit python. So we have both packages where
the architecture matters and where not.

So for now perl, python, php, ocaml, apache, ... will not be
multiarchified.  Packages that depend on any one of those and are not
Architecture: all will be forced to have the same architecture as
perl, python, php, ocaml, apache, ... itself.

If your package is a plugin or language binding then you do nothing.
If your package only contains a script or connects to a service then
pick one of 1-3,5 but leave the "Depends: python" (or whatever it is)
as is.


5) none of the above


Nothing above did fit? Multiarch makes no sense for your package?
You have no time to implement those changes?

So you do nothing. Doing nothing is the safe option. Doing nothing
might be perfectly alright. Your package will not be multiarchified.
If that is a hinderance I'm sure someone will beat you with a cluebat
or send you patches. Don't be afraid to ask for help and if you do get
patches welcome them.

Examples (in no way complete) where doing nothing it ok:

The -dev packages will not be multiarchified in the first round. Maybe
not in the second. Only thing you need to do in -dev packages is
adjust the *.so link to match the library package.

Your package is a leaf package or i

Re: Please test eglibc 2.9-23+multiarch

[Aurelien Jarno]

On Wed, Jul 29, 2009 at 01:56:40PM +0200, Sven Joachim wrote:
> On 2009-07-28 19:44 +0200, Aurelien Jarno wrote:
> 
> > I have recently uploaded to experimental eglibc 2.9-23+multiarch, from 
> > our multiarch branch. It doesn't use the multiarch paths yet, but it is
> > a first step toward multiarch. 
> >
> > The only difference with the unstable version is that libc-bin and
> > libc-dev-bin are splitted out of libc6 and libc6-dev. This way it
> > complies with the Debian Policy requirement that the libraries should 
> > not contain binaries, which is also a requirement for multiarch.
> >
> > Please test it and report possible problems related to this package
> > split. If no problem are detected, it will be uploaded to unstable as
> > soon as the current version migrates to testing. This way it will leave
> > space in experimental for eglibc 2.10.
> >
> > Note that it is currently not yet available on all architectures, please
> > wait for the experimental buildds to do their jobs.
> 
> I was not patient enough for that and built the packages myself instead
> on i386.  The result is not quite satisfactory, in a Lenny chroot they
> cannot be installed due to a dependency cycle:
> 
> ,
> | # cat /etc/debian_version 
> | 5.0.2
> | turtle:/# LANG=C apt-get dist-upgrade
> | Reading package lists... Done
> | Building dependency tree   
> | Reading state information... Done
> | Calculating upgrade... Done
> | The following NEW packages will be installed:
> |   libc-bin
> | The following packages will be upgraded:
> |   libc6 libc6-dev locales
> | 3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> | Need to get 0B/13.9MB of archives.
> | After this operation, 6042kB of additional disk space will be used.
> | Do you want to continue [Y/n]? 
> | WARNING: The following packages cannot be authenticated!
> |   libc6-dev locales libc6 libc-bin
> | Install these packages without verification [y/N]? y
> | E: Couldn't configure pre-depend libc-bin for libc6, probably a dependency 
> cycle.
> `
> 
> Same problem with aptitude, and this is the reason: libc6
> 2.9-23+multiarch Pre-Depends on libc-bin (= 2.9-23+multiarch) which in
> turn Depends on libc6 (>> 2.9), so if you didn't have libc6 2.9-x
> already installed, you're hosed.
> 

Thanks, it's something I forgot to test, I only tested squeeze to
experimental upgrades.

I have been told offline that the "Pre-Depends:" also breaks
debootstrap, so it should probably be switched to a Depends.

"Pre-Depends:" has been chosen because two binaries are important in
libc-bin and we have to make sure to not break the system:
- /sbin/ldconfig which is used to configure the ld.so cache. It should
  not be necessary during an upgrade as ld.so is smart enough to look by
  itself in the standard paths if the cache is out of date. If a package
  rely on ldconfig to add a new search path in is postinst, it should 
  depends on libc6 and thus on libc-bin, and that is enough to ensures
  that /sbin/ldconfig is there.
- /usr/lib/pt_chown is used to change the permissions of the terminal
  when grantpt(3) is called. On GNU/Linux, it is only useful if /dev/pts
  is not mounted, and if one wants to login as non-root. On GNU/kFreeBSD
  it is not used due to the use of devfs.

In short it looks like a Pre-Depends is overkill, and that a Depends is 
enough. I'll upload a new version soon to experimental to fix that.

Cheers,
Aurelien

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Hi,

small add on.

Any package in debian can be multiarchified at any time. You do not
have to wait for all your depends to be multiarchified or notifiy your
reverse depends when you are ready. The state of your depends will
only matter when someone actualy does a multiarch installation and
apt/dpkg will figure out by themself if all the depends are ready or
not. The current apt/dpkg will just ignore the multiarchifying.

Multiarchifying your package does not hurt the installability in any
way. It can only help.

MfG
Goswin

PS: If every DD would patch one package we would be way past the "99%
of all users are happy" goal. The norml use set of libraries for
32/64bit is about 150 library packages (less source packages).


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

Re: dash pulled on stable when APT::Default-Release is used

[Michael S. Gilbert]

On Wed, 29 Jul 2009 13:00:13 +0200, Felix Zielcke wrote:
> Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean:
> > Hi,
> > 
> >   Since a few days, on a stable machine (with stable, testing and
> > unstable sources for apt but APT::Default-Release set to "stable"),
> > "apt-get dist-upgrade" wants to install dash.
> >   Can someone explain me why ? Is it due to the fact that dash is
> > essential in unstable ?
> 
> I assume it is. 
> I thought I read somewhere that the reason why bash started to depend on
> dash would be that apt doestn't pull in new essential packages. Though
> on IRC I was told it does that already for a long time.
> 
> So if you don't want dash installed to be on a system which mainly uses
> stable you have to remove unstable from sources.list
> 
> But I think dash doestn't hurt, it's small and I use it as /bin/sh since
> a year or so without problems.

i think the real issue here is that getting dash pushed onto your stable
system is a somewhat unwelcome surprise (not that it is necessarily
harmful). it will certainly cause some concern for certain
security-conscious users since it is not coming from a point release or
DSA update, which may lead to paranoia of malicious activity.

perhaps an announcement should be made to state that this action is
expected and ok.

mike


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Paul Wise wrote:
> I note that you plan to modify the helper tools
> (debhelper/cdbs/yada/etc). I think that you will get better coverage
> by modifying dpkg-dev instead. Have you not considered that option or
> am I missing a disadvantage of it?

I tried to think in another level that would cover more packages than helper
tools. The problem I see with dpkg-dev is that it's not "the way" to build
packages (you can simply call ./debian/rules binary AFAIK), and I'm not sure
where I would create them; I guess dpkg-gencontrol would be the most appropriate
place, but we have the same problem than with helper tools: not every package
uses it. So I don't see any benefit with using dpkg-dev, and some problems (like
packages being stripped when dpkg-dev is called as dpkg-buildpackage may not
have been used to build the package).

> Thanks for working on this, it is really great to see it happening finally.

Thanks for your feedback!

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Wed, Jul 29 2009, Emilio Pozuelo Monfort wrote:

> Hi folks,
>
> I proposed [1] a GSoC project this spring which was accepted, and I'm thus
> working on getting automatic debug packages into Debian.
>
> The reasons for this are, among others, that adding -dbg packages to
> thousands of packages doesn't scale, that they bloat the archive and
> mirrors, and the ability to use debugging symbols over the network by
> using build-ids.
>
> The proposal is (very briefly) to make dak accept .ddeb packages
> (containing debugging symbols using build-ids), and to then modify
> helper tools to automatically generate them and add them to the
> changes file. I've written down the details in the wiki [2], and I'll
> appreciate it if you could give some feeback. I don't want to trash
> this completely though, so no drastic changes preferred :)

I think that we would need a clear policy of what packages are
 expected to do as well. Policy does not mandate that helper packages be
 used in Debian packages, and we can't suddenly start mandating that
 they be used.

So, we figure out first exactly what needs to be done, and then
 the helper packages implement that standard; as opposed to the standard
 being whatever the current helper package implementation happens to be.

I am not sure if an existing dpkg tool can be modified to do
 this, but I would be delighted to be proved wrong.

manoj 
-- 
How can you have any pudding if you don't eat your meat? Pink Floyd
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: Automatic Debug Packages

[Michael Banck]

On Wed, Jul 29, 2009 at 03:55:20PM +0200, Paul Wise wrote:
> On Wed, Jul 29, 2009 at 3:29 PM, Michael Banck wrote:
> 
> > AFAIK, dpkg-dev is only invoked at source-unpack and package-build time,
> > i.e. you need a full DEBIAN/ directory for dpkg-dev to act on.
> >
> > At that time, either you have thrown away the debugging information
> > already (via dh_strip, e.g.), or not.
> 
> I was thinking DEB_BUILD_OPTIONS=nostrip would be set by dpkg-buildpackage.

Oh, ok.


Michael


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

Re: Automatic Debug Packages

[Michael Banck]

On Wed, Jul 29, 2009 at 04:58:39PM +0200, Emilio Pozuelo Monfort wrote:
> Paul Wise wrote:
> > I note that you plan to modify the helper tools
> > (debhelper/cdbs/yada/etc). I think that you will get better coverage
> > by modifying dpkg-dev instead. Have you not considered that option or
> > am I missing a disadvantage of it?
> 
> I tried to think in another level that would cover more packages than helper
> tools. The problem I see with dpkg-dev is that it's not "the way" to build
> packages (you can simply call ./debian/rules binary AFAIK), and I'm not sure
> where I would create them; I guess dpkg-gencontrol would be the most 
> appropriate
> place, but we have the same problem than with helper tools: not every package
> uses it. So I don't see any benefit with using dpkg-dev, and some problems 
> (like
> packages being stripped when dpkg-dev is called as dpkg-buildpackage may not
> have been used to build the package).

Maybe it is reasonable to expect the package gets built on the buildd?
AIUI, this is the way Debian is heading anyway.

So while it is not required to build a .deb via dpkg-buildpackage; .debs
distributed by Debian will be at some point.


Michael


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

Re: Introduction to multiarch: What maintainers must do

[Manoj Srivastava]

On Wed, Jul 29 2009, Goswin von Brederlow wrote:

> Hi,
>
> small add on.
>
> Any package in debian can be multiarchified at any time. You do not
> have to wait for all your depends to be multiarchified or notifiy your
> reverse depends when you are ready. The state of your depends will
> only matter when someone actualy does a multiarch installation and
> apt/dpkg will figure out by themself if all the depends are ready or
> not. The current apt/dpkg will just ignore the multiarchifying.
>
> Multiarchifying your package does not hurt the installability in any
> way. It can only help.

My first thought was "Err. Won't moving all the shared libs into
 a different location kinda screw things up?" And then I looked, and
 found

,
| ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
| # Multiarch support
| /lib/x86_64-linux-gnu
| /usr/lib/x86_64-linux-gnu
| __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
| libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
`


manoj
-- 
"Luke, I'm yer father, eh.  Come over to the dark side, you hoser." Dave
Thomas, "Strange Brew"
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

Bug#539183: ITP: rapid-photo-downloader -- Photo downloader (importer) from cameras, memory cards other devices

[Julien Valroff]

Package: wnpp
Severity: wishlist
Owner: Julien Valroff 

* Package name: rapid-photo-downloader
  Version : 0.0.10
  Upstream Author : Damon Lynch 
* URL : http://damonlynch.net/rapid
* License : GPL
  Programming Lang: Python
  Description : Photo downloader (importer) from cameras, memory cards 
other devices

 Rapid Photo Downloader is written by a photographer for professional and
 amateur photographers. It can  download photos from multiple cameras,
 memory cards and Portable Storage Devices simultaneously. It provides many
 options for subfolder creation, image renaming and backup.





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

Re: Re: Introduction to multiarch: What maintainers must do

[sthibault]

> My first thought was "Err. Won't moving all the shared libs into a
> different location kinda screw things up?" And then I looked, and found
> 
> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==

Yes, but however pkg-config won't yet find things in
/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
in /usr/lib/pkgconfig.

Samuel


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Manoj Srivastava  writes:

> On Wed, Jul 29 2009, Goswin von Brederlow wrote:
>
>> Hi,
>>
>> small add on.
>>
>> Any package in debian can be multiarchified at any time. You do not
>> have to wait for all your depends to be multiarchified or notifiy your
>> reverse depends when you are ready. The state of your depends will
>> only matter when someone actualy does a multiarch installation and
>> apt/dpkg will figure out by themself if all the depends are ready or
>> not. The current apt/dpkg will just ignore the multiarchifying.
>>
>> Multiarchifying your package does not hurt the installability in any
>> way. It can only help.
>
> My first thought was "Err. Won't moving all the shared libs into
>  a different location kinda screw things up?" And then I looked, and
>  found
>
> ,
> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> | # Multiarch support
> | /lib/x86_64-linux-gnu
> | /usr/lib/x86_64-linux-gnu
> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> `
>
>
> manoj

Runtime support has been there a long time. Even sarge I think.

# ldconfig -v | grep /  
/usr/lib/i486-linux-gnu:
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/lib:
/lib32:
/usr/lib:
/usr/lib32:
/usr/lib/i486-linux-gnu/i686: (hwcap: 0x0008)
/usr/lib/tls: (hwcap: 0x8000)
/usr/lib32/i486: (hwcap: 0x0002)
/usr/lib32/i686: (hwcap: 0x0008)
/usr/lib32/i586: (hwcap: 0x0004)
/usr/lib/i486-linux-gnu/i686/cmov: (hwcap: 0x00088000)
/usr/lib32/i686/cmov: (hwcap: 0x00088000)

Even hwcaps function within multiarch dirs.

MfG
Goswin


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

Re: Introduction to multiarch: What maintainers must do

[Peter Samuelson]

Thanks for this excellent post, Goswin.

[Goswin von Brederlow]
> 3) Library package
> --
> 
>   a) Follow Policy 8.2 (MUST directive)
>  No conffiles, no binaries in the library package, no shared files
>  (/usr/share/doc/package/ is excempt and dpkg will handle that).

Policy does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
it is specific to the soname) - but it sounds like that will break
library multiarch too.  Can we have an exception for this?  It seems
silly to require a libfoo0-l10n package for every localized library.
-- 
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: Introduction to multiarch: What maintainers must do

[Steve Langasek]

On Wed, Jul 29, 2009 at 11:53:37AM -0500, Peter Samuelson wrote:

> Thanks for this excellent post, Goswin.

> [Goswin von Brederlow]
> > 3) Library package
> > --
> > 
> >   a) Follow Policy 8.2 (MUST directive)
> >  No conffiles, no binaries in the library package, no shared files
> >  (/usr/share/doc/package/ is excempt and dpkg will handle that).

> Policy does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
> it is specific to the soname) - but it sounds like that will break
> library multiarch too.  Can we have an exception for this?  It seems
> silly to require a libfoo0-l10n package for every localized library.

No exception is needed.  The current proposed multiarch design doesn't
prohibit /usr/share/locale* files in library packages; the only requirement
is that any files shipped there are identical between packages of the same
version for multiple architectures.

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


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

sthiba...@debian.org writes:

>> My first thought was "Err. Won't moving all the shared libs into a
>> different location kinda screw things up?" And then I looked, and found
>> 
>>| ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
>
> Yes, but however pkg-config won't yet find things in
> /usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
> in /usr/lib/pkgconfig.
>
> Samuel

Where do they actualy belong. I would have said the -dev package
(which are to be left alone in round 1). But:

libaudiofile-dev: /usr/lib/pkgconfig/audiofile.pc
libsdl-gfx1.2-4: /usr/lib/pkgconfig/SDL_gfx.pc

The second seems to be in clear violation of Policy 8.2.

MfG
Goswin


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

Re: dash pulled on stable when APT::Default-Release is used

[Vincent Danjean]

Michael S. Gilbert wrote:
>> Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean:
>>> Hi,
>>>
>>>   Since a few days, on a stable machine (with stable, testing and
>>> unstable sources for apt but APT::Default-Release set to "stable"),
>>> "apt-get dist-upgrade" wants to install dash.
>>>   Can someone explain me why ? Is it due to the fact that dash is
>>> essential in unstable ?

> i think the real issue here is that getting dash pushed onto your stable
> system is a somewhat unwelcome surprise (not that it is necessarily
> harmful). it will certainly cause some concern for certain
> security-conscious users since it is not coming from a point release or
> DSA update, which may lead to paranoia of malicious activity.

You need to have unstable sources in apt for this to occur. A plain
stable (lenny) system will not see that. It is not really a concern for
me (the lenny dash that is pulled does not change /bin/sh by default
and dash is not a big package).
  I was just wondering if this behavior was a feature or a bug. And it
was also a surprise for me.

> perhaps an announcement should be made to state that this action is
> expected and ok.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Re: Introduction to multiarch: What maintainers must do

[Henning Glawe]

On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
> My first thought was "Err. Won't moving all the shared libs into
>  a different location kinda screw things up?" And then I looked, and
>  found
> 
> ,
> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> | # Multiarch support
> | /lib/x86_64-linux-gnu
> | /usr/lib/x86_64-linux-gnu
> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> `

side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
this intentionally excluded or simply forgotten?


-- 
c u
henning


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

Re: Introduction to multiarch: What maintainers must do

[Samuel Thibault]

Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> the only requirement is that any files shipped there are identical
> between packages of the same version for multiple architectures.

That's however not true for .mo files, for endianness, typically.

Samuel


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

Re: Introduction to multiarch: What maintainers must do

[Samuel Thibault]

Goswin von Brederlow, le Wed 29 Jul 2009 19:09:59 +0200, a écrit :
> sthiba...@debian.org writes:
> 
> >> My first thought was "Err. Won't moving all the shared libs into a
> >> different location kinda screw things up?" And then I looked, and found
> >> 
> >>  | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> >
> > Yes, but however pkg-config won't yet find things in
> > /usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
> > in /usr/lib/pkgconfig.
> 
> Where do they actualy belong. I would have said the -dev package
> (which are to be left alone in round 1).

Yes. However, passing --libdir to ./configure makes everything go to
/usr/lib/x86_64-linux-gnu/, including pkgconfig files, that's why we
should take care of that.

> libsdl-gfx1.2-4: /usr/lib/pkgconfig/SDL_gfx.pc
> 
> The second seems to be in clear violation of Policy 8.2.

Yes.

Samuel


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

Re: dash pulled on stable when APT::Default-Release is used

[Michael S. Gilbert]

On Wed, 29 Jul 2009 19:20:02 +0200, Vincent Danjean wrote:
> Michael S. Gilbert wrote:
> >> Am Mittwoch, den 29.07.2009, 02:25 +0200 schrieb Vincent Danjean:
> >>> Hi,
> >>>
> >>>   Since a few days, on a stable machine (with stable, testing and
> >>> unstable sources for apt but APT::Default-Release set to "stable"),
> >>> "apt-get dist-upgrade" wants to install dash.
> >>>   Can someone explain me why ? Is it due to the fact that dash is
> >>> essential in unstable ?
> 
> > i think the real issue here is that getting dash pushed onto your stable
> > system is a somewhat unwelcome surprise (not that it is necessarily
> > harmful). it will certainly cause some concern for certain
> > security-conscious users since it is not coming from a point release or
> > DSA update, which may lead to paranoia of malicious activity.
> 
> You need to have unstable sources in apt for this to occur. A plain
> stable (lenny) system will not see that. It is not really a concern for
> me (the lenny dash that is pulled does not change /bin/sh by default
> and dash is not a big package).
>   I was just wondering if this behavior was a feature or a bug. And it
> was also a surprise for me.

it is a bug in the sense that stable's behavior is being unduly
influenced by unstable's "essential packages" list.  i would suggest
submitting a report to the bts so the problem can be tracked and
eliminated in future releases.

mike


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Michael Banck wrote:
> Maybe it is reasonable to expect the package gets built on the buildd?
> AIUI, this is the way Debian is heading anyway.
> 
> So while it is not required to build a .deb via dpkg-buildpackage; .debs
> distributed by Debian will be at some point.

I saw some complaints in debian-policy when this issue (dpkg-buildpackage by
default, and it setting some env variables) came to the list, so I'm not sure
there's consensus about that. If there is, I could try that approach (which may
probably be better than helper tools), but if there's not I'm not sure, as we
want build reproducibility.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

multiarch: dependency-oriented vs package-oriented

[Eugene V. Lyubimkin]

Hi Goswin, hi -devel,

I would somewhat object to Multi-Arch field in the long run, and here are my
thoughts.

What the multiarch spec proposes now is package-oriented approach: the package
should define whether it is 'same' or 'foreign' kind. This is not
straightforward, because in fact not the package decides it's multiarch
'role', but its reverse dependencies. Only they 'decide' they want to
arch-dependent package 'functionality' or arch-independent one. From the
package manager PoV (dpkg and its frontends) I find dependency-oriented
multiarch info is more clearer and easier to implement.

Goswin, as you are already noted, the packages which are known to have both
kind of dependencies - at least, some interpreters - have nothing to do with
that Multi-Arch field, and to handle them, you'll have to put this info in the
package that is dependent on this interpreter in the long run.

Moreover, this is not the only exception. Thousands of desktop and server
packages that contains executable binaries (applications) compiled from
C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With
'arch:all' packages being not a problem at all fortunately, there are only one
(?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
library packages for compiled languages which are always multiarch 'same', but
they also already special-cased/handled by various tools like dpkg-shlibdeps,
dpkg-genshlibs, and it would been possible to even generate runtime
dependencies ({shlibs:Depends}) with proper multiarch dependency info without
even bothering the maintainer to do it.

For the upgrade path, we can stick default multiarch 'same' to the all
packages in archive, so implementing multiarch support won't broke anything at
all at all without changing nor source not binary packages at this moment, and
the maintainers are free to bother ourselves to mark some dependencies as
multiarch 'same' to allow foreign dependencies to be satisfied with less
number of packages in the system in the long run.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Re: Introduction to multiarch: What maintainers must do

[Peter Samuelson]

> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > the only requirement is that any files shipped there are identical
> > between packages of the same version for multiple architectures.

[Samuel Thibault]
> That's however not true for .mo files, for endianness, typically.

So what does this mean for /usr/share/locale and multiarch?  Do we need
to move to /usr/lib/{gnu-type}/locale?
-- 
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: Introduction to multiarch: What maintainers must do

[Steve Langasek]

On Wed, Jul 29, 2009 at 01:41:20PM -0500, Peter Samuelson wrote:

> > Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > > the only requirement is that any files shipped there are identical
> > > between packages of the same version for multiple architectures.

> [Samuel Thibault]
> > That's however not true for .mo files, for endianness, typically.

> So what does this mean for /usr/share/locale and multiarch?  Do we need
> to move to /usr/lib/{gnu-type}/locale?

My understanding is that .mo files include an endianness tag, so files of
either endianness can be loaded on any system.  It might be simpler to pick
a format to use for multiarch packages, so that these can continue to be
shipped in the library package.

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


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

Re: multiarch: dependency-oriented vs package-oriented

[Steve Langasek]

Hi Eugene,

On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:

> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.

First, why do these packages need to be cross-installed?  If they don't need
to be, then there's no reason to set the Multi-Arch field on them at all.

Second, why does the Multi-Arch: allowed option not implement what you need?

It seems ok to me if Multi-Arch: allowed eventually becomes the dominant use
case.  But there aren't thousands of packages in Debian with "-dbg"
reverse-dependencies, anyway, so this seems to be a complete non-issue in
the short term.

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


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

Re: multiarch: dependency-oriented vs package-oriented

[Eugene V. Lyubimkin]

Hi Steve,

Steve Langasek wrote:
> Hi Eugene,
> 
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
> 
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.
> 
> First, why do these packages need to be cross-installed?

If Debian is going to adopt multiarch, the spec should cover all packages.
Well... here is: one of multiarch stories in Ubuntu multiarch specification
contains an paragraph about the man who installs armel packages on his amd64.
He may easily want to debug those armel packages :)

> Second, why does the Multi-Arch: allowed option not implement what you need?
> 
> It seems ok to me if Multi-Arch: allowed eventually becomes the dominant use
> case.  But there aren't thousands of packages in Debian with "-dbg"
> reverse-dependencies, anyway, so this seems to be a complete non-issue in
> the short term.
> 
My point is: I see not much arguments to implement 'Multi-Arch'
package-oriented field at all, as it won't work for all cases in the short
term, and will be anyway replaced in the long term, plus there is (I think,
but one may object) a possibility to implement multiarch support without it,
which I tried to describe.

Less and simpler changes -> that's my goal.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer



signature.asc
Description: OpenPGP digital signature

Re: Introduction to multiarch: What maintainers must do

[Samuel Thibault]

Peter Samuelson, le Wed 29 Jul 2009 13:41:20 -0500, a écrit :
> 
> > Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > > the only requirement is that any files shipped there are identical
> > > between packages of the same version for multiple architectures.
> 
> [Samuel Thibault]
> > That's however not true for .mo files, for endianness, typically.

Mmm, on second though, maybe not, as I can find quite a few arch:all
packages containing them.  I now remember some thread about that on
debian-devel.

Samuel


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Samuel Thibault  writes:

> Goswin von Brederlow, le Wed 29 Jul 2009 19:09:59 +0200, a écrit :
>> sthiba...@debian.org writes:
>> 
>> >> My first thought was "Err. Won't moving all the shared libs into a
>> >> different location kinda screw things up?" And then I looked, and found
>> >> 
>> >> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
>> >
>> > Yes, but however pkg-config won't yet find things in
>> > /usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files
>> > in /usr/lib/pkgconfig.
>> 
>> Where do they actualy belong. I would have said the -dev package
>> (which are to be left alone in round 1).
>
> Yes. However, passing --libdir to ./configure makes everything go to
> /usr/lib/x86_64-linux-gnu/, including pkgconfig files, that's why we
> should take care of that.
>
>> libsdl-gfx1.2-4: /usr/lib/pkgconfig/SDL_gfx.pc
>> 
>> The second seems to be in clear violation of Policy 8.2.
>
> Yes.
>
> Samuel

Any of the lintian people reading this?

Could we create a check for *.pc files that they are in the right
place and right package in anticipation of multiarch? Wrong package
already is a bug and wrong place seems to be a likely bug to happen.

MfG
Goswin


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> I think that we would need a clear policy of what packages are
>  expected to do as well. Policy does not mandate that helper packages be
>  used in Debian packages, and we can't suddenly start mandating that
>  they be used.

I think you misunderstood it. The archive would start to accept .ddebs, but they
won't be mandatory. Then packages using debhelper/whatever would build .ddeb
packages if appropriate, but packages not using helper tools would keep working
as they do now, not building .ddebs (not automatically by debhelper at least,
but they could build them manually or use some other mechanism) and would still
be accepted. So nothing would be forced to use helper tools. It's rather that if
you want automatic .ddeb packages, you can get them with debhelper, but you can
build them manually or use something else if you wish. Not ideal, but I haven't
found a better alternative.

> So, we figure out first exactly what needs to be done, and then
>  the helper packages implement that standard; as opposed to the standard
>  being whatever the current helper package implementation happens to be.

That would be, packages may start to build .ddeb packages. Then helper tools or
packages themselves can do the work to build them. For helper tools, we would
get them automatically without any changes to the packages themselves, and
that's something around 97% of the archive.

> I am not sure if an existing dpkg tool can be modified to do
>  this, but I would be delighted to be proved wrong.

Even if it was possible, you still wouldn't get 100% coverage, as not every
package uses dpkg-dev. So this is the same problem as with helper tools, except
that with helper tools, packages not using them can build .ddebs manually (or
automatize it somehow).

I don't know how it could be implemented in dpkg-dev anyway. dpkg-buildpackage
sounds like the right place to do it, but before it calls the binary target is
too soon, and after it is too late.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Please test eglibc 2.9-23+multiarch.1 (was Re: Please test eglibc 2.9-23+multiarch)

[Aurelien Jarno]

On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
> In short it looks like a Pre-Depends is overkill, and that a Depends is 
> enough. I'll upload a new version soon to experimental to fix that.
> 

eglibc version 2.9-23+multiarch.1 is now in incoming and will be on the
mirrors soon. Please test and report problems.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: Introduction to multiarch: What maintainers must do

[Russ Allbery]

Samuel Thibault  writes:
> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :

>> the only requirement is that any files shipped there are identical
>> between packages of the same version for multiple architectures.
>
> That's however not true for .mo files, for endianness, typically.

However, you *can* share the same .mo files on each platform, since the
gettext code copes with endianness issues at runtime if need be.

-- 
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: Introduction to multiarch: What maintainers must do

[Russ Allbery]

Goswin von Brederlow  writes:

> Any of the lintian people reading this?

Yes, but only very intermittantly between other things since I'm on
semi-vacation this week.

> Could we create a check for *.pc files that they are in the right
> place and right package in anticipation of multiarch? Wrong package
> already is a bug and wrong place seems to be a likely bug to happen.

Could you file a bug against lintian so that we don't lose track?

-- 
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: Automatic Debug Packages

[Manoj Srivastava]

On Wed, Jul 29 2009, Emilio Pozuelo Monfort wrote:

> Manoj Srivastava wrote:
>> I think that we would need a clear policy of what packages are
>>  expected to do as well. Policy does not mandate that helper packages be
>>  used in Debian packages, and we can't suddenly start mandating that
>>  they be used.
>
> I think you misunderstood it. The archive would start to accept
> .ddebs, but they won't be mandatory. Then packages using
> debhelper/whatever would build .ddeb packages if appropriate, but
> packages not using helper tools would keep working as they do now, not
> building .ddebs (not automatically by debhelper at least, but they
> could build them manually or use some other mechanism) and would still
> be accepted. So nothing would be forced to use helper tools. It's
> rather that if you want automatic .ddeb packages, you can get them
> with debhelper, but you can build them manually or use something else
> if you wish. Not ideal, but I haven't found a better alternative.

On the contrary, I think you are missing the point. The
 work-unit put in by developers is not the only issue this brings up,

We do not want to have different helper package start inventing
 a helper specific way of building  ddebs, with no clear standard tha
 they are following.

>> So, we figure out first exactly what needs to be done, and then
>>  the helper packages implement that standard; as opposed to the standard
>>  being whatever the current helper package implementation happens to be.
>
> That would be, packages may start to build .ddeb packages. Then helper
> tools or packages themselves can do the work to build them. For helper
> tools, we would get them automatically without any changes to the
> packages themselves, and that's something around 97% of the archive.

While archive coverage is nice, ensuring  that a ddeb is
 properly defined, and that all the different ways of creating ddebs are
 consistent, should happen first.

Coming up with a standard and policy after the fact, with 97% of
 the archive not quite following policy would be a nightmare, no?

manoj
-- 
Chown up.  Chow down.
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: Automatic Debug Packages

[Cyril Brulebois]

Manoj Srivastava  (29/07/2009):
> Coming up with a standard and policy after the fact, with 97% of
>  the archive not quite following policy would be a nightmare, no?

97% of the archive using yada?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Sune Vuorela]

On 2009-07-29, Manoj Srivastava  wrote:
> On the contrary, I think you are missing the point. The
>  work-unit put in by developers is not the only issue this brings up,
>
> We do not want to have different helper package start inventing
>  a helper specific way of building  ddebs, with no clear standard tha
>  they are following.

instead of objcopy and stuff people current do, either manually or with
the help of dh_strip and wrap it in a foo-dbg.deb by using the
.gnu_debuglink to and the expected paths by gdb and friends on where to
find it, instead use the newfangled build id and put it in a appropriate
hashed directory structure, as gdb and friends also are able to pick up,
and then wrap it in a foo.ddeb package.

There is nothing actually magic in it, except making it easy to use, but
for more technical details, 
see the --build-id option to ld(1) for more details about what build-id is
and the gdb manual chapter 15.2 for more info about debugging
information in seperate files.

/Sune


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

Re: multiarch: dependency-oriented vs package-oriented

[Goswin von Brederlow]

Discussions should probably go to debian-dpkg.

"Eugene V. Lyubimkin"  writes:

> Hi Goswin, hi -devel,
>
> I would somewhat object to Multi-Arch field in the long run, and here are my
> thoughts.
>
> What the multiarch spec proposes now is package-oriented approach: the package
> should define whether it is 'same' or 'foreign' kind. This is not
> straightforward, because in fact not the package decides it's multiarch
> 'role', but its reverse dependencies. Only they 'decide' they want to
> arch-dependent package 'functionality' or arch-independent one. From the
> package manager PoV (dpkg and its frontends) I find dependency-oriented
> multiarch info is more clearer and easier to implement.

For most things the depended on package decided what its interface
is. Wether it provides a command line interface (sed) or a binary
interface (libfoo.so.X) to the world. This is usually clear cut.

The reason why we want to define this in the depended on package is
threefold:

1) Many packages depend on a few libraries. If we tag the few
libraries all the depending packages become installable. Less work.

2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right (and those are manual depends apart from libs)
and making package relationships in every package longer. Packages
files are HUGE already:
-rw-r--r-- 1 root root 27M Jul 24 18:35 
/var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages

3) 3rd party packages are verry hard to change. Lets face it, on amd64
a major reason for doing this is to get those 3rd party products
running that still haven't managed to build 64bit versions. Getting
them to tag their packages and tag them right would take forever. It
is way to easy for them to tag something wrong.


But there is another reason, a reason why we must:

A library package must say if it is coinstallable for multiple
architectures or not. Must say if it was multiarchified or not. Just
because some package depends on a libary with some "same architecture"
flags in no way means that library is multiarchified. So we need every
library package to say "Multi-Arch: same" when it has moved its
library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
that information also for package relationships as well? Adding the
"same" flag in both the library and the depends seems stupid.

Without the flag in each library it would be way to easy for packages
to screw the system and multiarchifying would have to be in strict
order of dependencies, with lots of transitions and lots of versioned
depends and so on. Verry ugly.

And if we have "Multi-Arch: same" then also doing "Multi-Arch:
foreign" seems logical. No point in manually flagging package
relationships on binaries but autodetect package relationships on
libraries. I rather flag one binary package than 500 reverse depends
on it. The problem cases really are the exception (ignoring the -dbg
packages below, that should use magic in the package managers). A mere
handfull out of 20k packages.


> Goswin, as you are already noted, the packages which are known to have both
> kind of dependencies - at least, some interpreters - have nothing to do with
> that Multi-Arch field, and to handle them, you'll have to put this info in the
> package that is dependent on this interpreter in the long run.
>
> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With
> 'arch:all' packages being not a problem at all fortunately, there are only one
> (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
> library packages for compiled languages which are always multiarch 'same', but
> they also already special-cased/handled by various tools like dpkg-shlibdeps,
> dpkg-genshlibs, and it would been possible to even generate runtime
> dependencies ({shlibs:Depends}) with proper multiarch dependency info without
> even bothering the maintainer to do it.

You raise an interesting point there with -dbg packages. Esspecially
considering the Google SoC project that wants to automatically build
-dbg packages for everything in debian. Those .ddeb packages. Too me
it seems that .ddeb packages seem like a really good idea and teaching
the package management system that .ddeb packages must match the
architecture no matter what the .deb says seems like the solution to
your example. The -dbg packages could be handled all in one go
magically. So do you have another example besides -dbg packages?

I myself am not yet happy with the "Multi-Arch: allowed" feature as
solution. And I haven't heard all the rational behind it. Why it is
better than other suggestions from the past. It is something that has
been added to the

Re: multiarch: dependency-oriented vs package-oriented

[Goswin von Brederlow]

Steve Langasek  writes:

> Hi Eugene,
>
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.
>
> First, why do these packages need to be cross-installed?  If they don't need
> to be, then there's no reason to set the Multi-Arch field on them at all.

I want zsh for be "Multi-Arch: foreign" so zomg:i386 and
flowscan:amd64 can be installed. But then zsh:amd64 and zsh-dbg:i386
would be installable, which clearly does not give functional debugging
symbols.

-dbg packages are a valid concern I think. But not a show stopper. One
that can be solved with a bit of magic. .ddeb packages would be a
solution benefiting users, multiarch and the archive and mirrors in
the long run. Till then -dbg packages can be detected by name in the
worst case.

> Second, why does the Multi-Arch: allowed option not implement what you need?
>
> It seems ok to me if Multi-Arch: allowed eventually becomes the dominant use
> case.  But there aren't thousands of packages in Debian with "-dbg"
> reverse-dependencies, anyway, so this seems to be a complete non-issue in
> the short term.

% apt-cache search -- -dbg | wc -l
920

Approaching *1* thousands of packages. :)

MfG
Goswin


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Henning Glawe  writes:

> On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
>> My first thought was "Err. Won't moving all the shared libs into
>>  a different location kinda screw things up?" And then I looked, and
>>  found
>> 
>> ,
>> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
>> | # Multiarch support
>> | /lib/x86_64-linux-gnu
>> | /usr/lib/x86_64-linux-gnu
>> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> `
>
> side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
> this intentionally excluded or simply forgotten?

--- libc6: /etc/ld.so.conf.d/libc.conf ---
# libc default configuration
/usr/local/lib

So where do we put /usr/local/lib/x86_64-linux-gnu now?

Eglibc maintainers, what do you think?

MfG
Goswin


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

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Hi gettext,

while talking about multiarch the issue was raised that

/usr/share/locale/*/*package.mo

is not identical across all architectures as multiarch would require.

Russ Allbery  writes:

> Samuel Thibault  writes:
>> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
>
>>> the only requirement is that any files shipped there are identical

there == /usr/share/

>>> between packages of the same version for multiple architectures.
>>
>> That's however not true for .mo files, for endianness, typically.
>
> However, you *can* share the same .mo files on each platform, since the
> gettext code copes with endianness issues at runtime if need be.

So we would have to define a default endianness for creating such
files. A patch to gettext to create them allways little endian (or the
other way) seems in order.

Thoughts from the maintainer?

MfG
Goswin


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

Re: multiarch: dependency-oriented vs package-oriented

[Eugene V. Lyubimkin]

Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin"  writes:
>> What the multiarch spec proposes now is package-oriented approach: the 
>> package
>> should define whether it is 'same' or 'foreign' kind. This is not
>> straightforward, because in fact not the package decides it's multiarch
>> 'role', but its reverse dependencies. Only they 'decide' they want to
>> arch-dependent package 'functionality' or arch-independent one. From the
>> package manager PoV (dpkg and its frontends) I find dependency-oriented
>> multiarch info is more clearer and easier to implement.
> 
> For most things the depended on package decided what its interface
> is. Wether it provides a command line interface (sed) or a binary
> interface (libfoo.so.X) to the world. This is usually clear cut.
Hm, no, not for all. Again, amarok-dbg depends on amarok in arch-dependent
way. And some others. Yes, no one provided sed-dbg yet :)

> 
> The reason why we want to define this in the depended on package is
> threefold:
> 
> 1) Many packages depend on a few libraries. If we tag the few
> libraries all the depending packages become installable. Less work.
Keeping existing relationships with existing syntax as 'multiarch:same' become
installable all packages. Without any work. Well, with all the dependency
tree, but for that libraries it's anyway the same case.

> 2) Tagging package relationships instead of packages means extending
> the syntax of package relationsships, trusting the binary packages to
> get the depends right
You'll have to do it sooner or later. At least for already mentioned perl,
python and others. Or no?

> and making package relationships in every package longer. Packages
> files are HUGE already:
> -rw-r--r-- 1 root root 27M Jul 24 18:35 
> /var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages
Well, "Multi-Arch: " would also make Packages longer.

> 
> 3) 3rd party packages are verry hard to change. Lets face it, on amd64
> a major reason for doing this is to get those 3rd party products
> running that still haven't managed to build 64bit versions. Getting
> them to tag their packages and tag them right would take forever. It
> is way to easy for them to tag something wrong.
Same answer as for 1).

> But there is another reason, a reason why we must:
> 
> A library package must say if it is coinstallable for multiple
> architectures or not. Must say if it was multiarchified or not. Just
> because some package depends on a libary with some "same architecture"
> flags in no way means that library is multiarchified. So we need every
> library package to say "Multi-Arch: same" when it has moved its
> library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
> that information also for package relationships as well?
Because, hm, this is different kind of info.

> Adding the
> "same" flag in both the library and the depends seems stupid.
Got it. I would still propose 'Multi-Arch: yes' only for mentioned purposes
(co-installability) and dependencies for others. But yes, this makes my point
more weak.

> on it. The problem cases really are the exception (ignoring the -dbg
> packages below, that should use magic in the package managers
mm? is it a part of a plan? urh, ugly

>> Goswin, as you are already noted, the packages which are known to have both
>> kind of dependencies - at least, some interpreters - have nothing to do with
>> that Multi-Arch field, and to handle them, you'll have to put this info in 
>> the
>> package that is dependent on this interpreter in the long run.
>>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. 
>> With
>> 'arch:all' packages being not a problem at all fortunately, there are only 
>> one
>> (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
>> library packages for compiled languages which are always multiarch 'same', 
>> but
>> they also already special-cased/handled by various tools like dpkg-shlibdeps,
>> dpkg-genshlibs, and it would been possible to even generate runtime
>> dependencies ({shlibs:Depends}) with proper multiarch dependency info without
>> even bothering the maintainer to do it.
> 
> You raise an interesting point there with -dbg packages. Esspecially
> considering the Google SoC project that wants to automatically build
> -dbg packages for everything in debian. Those .ddeb packages. Too me
> it seems that .ddeb packages seem like a really good idea and teaching
> the package management system that .ddeb packages must match the
> architecture no matter what the .deb says seems like the solution to
> your example. The -dbg packages could be handled all in one go
> magically. So do you have another example besides -dbg packages?
No, I noted all examples came to my find for

Re: Introduction to multiarch: What maintainers must do

[Goswin von Brederlow]

Russ Allbery  writes:

> Goswin von Brederlow  writes:
>
>> Any of the lintian people reading this?
>
> Yes, but only very intermittantly between other things since I'm on
> semi-vacation this week.
>
>> Could we create a check for *.pc files that they are in the right
>> place and right package in anticipation of multiarch? Wrong package
>> already is a bug and wrong place seems to be a likely bug to happen.
>
> Could you file a bug against lintian so that we don't lose track?

Done.

MfG
Goswin


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

Re: Introduction to multiarch: What maintainers must do

[Aurelien Jarno]

On Wed, Jul 29, 2009 at 11:33:51PM +0200, Goswin von Brederlow wrote:
> Henning Glawe  writes:
> 
> > On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
> >> My first thought was "Err. Won't moving all the shared libs into
> >>  a different location kinda screw things up?" And then I looked, and
> >>  found
> >> 
> >> ,
> >> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> >> | # Multiarch support
> >> | /lib/x86_64-linux-gnu
> >> | /usr/lib/x86_64-linux-gnu
> >> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> >> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> >> `
> >
> > side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
> > this intentionally excluded or simply forgotten?
> 
> --- libc6: /etc/ld.so.conf.d/libc.conf ---
> # libc default configuration
> /usr/local/lib
> 
> So where do we put /usr/local/lib/x86_64-linux-gnu now?
> 
> Eglibc maintainers, what do you think?
> 

We should add a config file for that, haven't think more about the
details.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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

Re: question about iptables and bug #538608

[Henrique de Moraes Holschuh]

On Wed, 29 Jul 2009, Francesco P. Lovergine wrote:
> At least in one case, I change the series file on-fly at building time
> to create different flavors of the same lib with a different patchset. 
> I roughly suspect this is not compatible with the 3.0 format, but it 
> is also difficult to be auto-detected...

Dear god! I hope your package has a debian/README.Source file explaining
that?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: multiarch: dependency-oriented vs package-oriented

[Goswin von Brederlow]

"Eugene V. Lyubimkin"  writes:

> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin"  writes:
>>> What the multiarch spec proposes now is package-oriented approach: the 
>>> package
>>> should define whether it is 'same' or 'foreign' kind. This is not
>>> straightforward, because in fact not the package decides it's multiarch
>>> 'role', but its reverse dependencies. Only they 'decide' they want to
>>> arch-dependent package 'functionality' or arch-independent one. From the
>>> package manager PoV (dpkg and its frontends) I find dependency-oriented
>>> multiarch info is more clearer and easier to implement.
>> 
>> For most things the depended on package decided what its interface
>> is. Wether it provides a command line interface (sed) or a binary
>> interface (libfoo.so.X) to the world. This is usually clear cut.
> Hm, no, not for all. Again, amarok-dbg depends on amarok in arch-dependent
> way. And some others. Yes, no one provided sed-dbg yet :)

-dbg is not the world. :)
 
>> The reason why we want to define this in the depended on package is
>> threefold:
>> 
>> 1) Many packages depend on a few libraries. If we tag the few
>> libraries all the depending packages become installable. Less work.
> Keeping existing relationships with existing syntax as 'multiarch:same' become
> installable all packages. Without any work. Well, with all the dependency
> tree, but for that libraries it's anyway the same case.

No, that just plain makes every package cause an override
conflict. That is the difference between no Multi-Arch field and
same. Same means packages are coinstallable. Apart from that no
Multi-Arch and same behave the same.

The Multi-Arch: same actualy is an improvement to your
suggestion. YOur suggestion is already in the specs for when no
Multi-Arch is specified.

>> 2) Tagging package relationships instead of packages means extending
>> the syntax of package relationsships, trusting the binary packages to
>> get the depends right
> You'll have to do it sooner or later. At least for already mentioned perl,
> python and others. Or no?

Yes, but how many are there. Perl for example has 2627 reverse
depends. How many of those are plugins?

>> and making package relationships in every package longer. Packages
>> files are HUGE already:
>> -rw-r--r-- 1 root root 27M Jul 24 18:35 
>> /var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages
> Well, "Multi-Arch: " would also make Packages longer.

But only one entry per package, not one entry per package
relation. Say a library has only 2 reverse depends. Tagging both with
":kfreebsd-amd64" will be longer than "Multi-Arch: same". And
libraries and binaries have a lot more reverse depends.
 
>> 3) 3rd party packages are verry hard to change. Lets face it, on amd64
>> a major reason for doing this is to get those 3rd party products
>> running that still haven't managed to build 64bit versions. Getting
>> them to tag their packages and tag them right would take forever. It
>> is way to easy for them to tag something wrong.
> Same answer as for 1).

No. Most 3rd party debs are leaf packages/cluster. Nothing needs to
happen there. Imagine packages as a tree sorted by dependencies. We
only need to tag the root but the far bigger crown can stay as
is. As mentioned before there are less than 200 packages in use in
biarch now.

>> But there is another reason, a reason why we must:
>> 
>> A library package must say if it is coinstallable for multiple
>> architectures or not. Must say if it was multiarchified or not. Just
>> because some package depends on a libary with some "same architecture"
>> flags in no way means that library is multiarchified. So we need every
>> library package to say "Multi-Arch: same" when it has moved its
>> library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
>> that information also for package relationships as well?
> Because, hm, this is different kind of info.
>
>> Adding the
>> "same" flag in both the library and the depends seems stupid.
> Got it. I would still propose 'Multi-Arch: yes' only for mentioned purposes
> (co-installability) and dependencies for others. But yes, this makes my point
> more weak.

Yeah, the earlier drafts did have yes/no but at that meeting the Ubuntu
draft was worded they somehow decided on same/foreign.

>> on it. The problem cases really are the exception (ignoring the -dbg
>> packages below, that should use magic in the package managers
> mm? is it a part of a plan? urh, ugly

Not yet.

>>> Goswin, as you are already noted, the packages which are known to have both
>>> kind of dependencies - at least, some interpreters - have nothing to do with
>>> that Multi-Arch field, and to handle them, you'll have to put this info in 
>>> the
>>> package that is dependent on this interpreter in the long run.
>>>
>>> Moreover, this is not the only exception. Thousands of desktop and server
>>> packages that contains executable binaries (applications) compiled from
>>> C/C++/Pascal/etc

Re: Introduction to multiarch: What maintainers must do

[Peter Samuelson]

[Goswin von Brederlow]
> 3) Library package
> --
> 
>   a) Follow Policy 8.2 (MUST directive)
>  No conffiles, no binaries in the library package, no shared files
>  (/usr/share/doc/package/ is excempt and dpkg will handle that).

We have mostly settled the /usr/share/locale question, and apparently
/usr/share/doc is a special exception anyway

But in case you need to install other stuff to /usr/share from a
library package: note that anything you compress with gzip, you should
use -n, so you'll get the same bits on every build.  And obviously
think about the same issues for other "generated" files in /usr/share.

I suppose /usr/share in library packages is fairly rare anyway.
-- 
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: Introduction to multiarch: What maintainers must do

[Steve Langasek]

On Wed, Jul 29, 2009 at 07:38:22PM -0500, Peter Samuelson wrote:
> We have mostly settled the /usr/share/locale question, and apparently
> /usr/share/doc is a special exception anyway

No, it is not.  The ubiquity of /usr/share/doc provides the *rationale* for
multiarch handling /usr/share in a way that doesn't require splitting out
common packages, but dpkg will not handle /usr/share/doc differently than
any other files.

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


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

Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)

[Daniel Jacobowitz]

On Sun, Jul 26, 2009 at 12:42:46AM +0200, Florian Weimer wrote:
> I've built a small proof-of-concept library which creates Java-style
> tracebacks for C and C++ programs.  In contrast to libc's backtrace()
> function, it uses DWARF debugging information when available, so the
> output is generally quite useful.  Debugging information is extracted
> from the main executable and any loaded DSOs, or from the shadow debug
> tree in /usr/lib/debug.

Can't you do this just by forking addr2line and providing a shim layer
that knows shared library load offsets?  That saves you the really
grotty bits.

-- 
Daniel Jacobowitz
CodeSourcery


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

Bug#539238: ITP: gearhead2 -- roguelike mecha role playing game in space

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula 

* Package name: gearhead2
  Version : 0.603
  Upstream Author : Joseph Hewitt 
* URL : http://www.gearheadrpg.com/
* License : LGPL v2.1 or later
  Programming Lang: Pascal
  Description : roguelike mecha role playing game in space

 Set a century and a half after nuclear war, you can explore a world
 where various factions compete to determine the future of the human
 race. Major features include random plot generation, a detailed
 character system, and over two hundred customizable mecha designs.
 .
 GearHead 2 is set five years after the events of GearHead 1. It is
 currently under development and is initially set in the L5 Orbital
 Pattern.



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

Re: Introduction to multiarch: What maintainers must do

[Charles Plessy]

Le Wed, Jul 29, 2009 at 03:57:31PM +0200, Goswin von Brederlow a écrit :
> 
> I got some good feedback from my previous Introduction to multiarch
> post and some good questions. I'm singling out Manoj Srivastava here
> because he was the most recent to ask this on irc but there where
> others with the same or simmilar question.
> 
> The full multiarch proposal can be read on:
>   https://wiki.ubuntu.com/MultiarchSpec

Dear Goswin,

thank you very much for your vulgarisation efforts. Multi-architecture settings
will be very useful for scientific computing, where we only want the
applications that really need 64 bits to use this, as there can be a
performance cost to use 64 bits in cases where 32 would be enough (which means:
spending taxpayer money to heat the atmosphere).

I have three questions about Multi-arch:

1) What is the advantage of adding a new field over simply using something like
   ‘Arch: multi’?

2) On the Ubuntu page I read: “It is worth noting that existing package
   management tools will be unable to interpret and satisfy package 
relationships
   of this format, even when the desired package is available. Consequently, it 
is
   recommended to defer use of such package relationships in the archive for a
   full release cycle following the package management implementation.” Does it
   mean that we need to postpone the implementation of multi-arch in perl 
packages
   containing compiled code until Squeeze + 2, to keep our promise to support
   upgrades from Lenny?


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine

[Russell Coker]

On Sun, 26 Jul 2009, Manoj Srivastava  wrote:
>         So the script is is only expected to tell if the machine it
>  finds itself running in happens to have the signature of a known
>  virtual machine flavour. It is not supposed to determine if it is
>  turtles all the way down.

Being able to scp that script to a random machine could be handy.  But what is 
the benefit in having it installed in Debian?  Anyone who has problems 
remembering which virtualisation technology is used for each virtual server 
could easily modify /etc/motd to have the full details.  The same access 
rights are required for installing a Debian package as for editing /etc/motd.

One thing that would be handy is a script that runs ssh to connect to a server 
and then interrogates it.  Such a script would ideally be able to identify 
various versions of BSD and Solaris as well.  Including the virt-what 
functionality in such a script would be good.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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