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 sc
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
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
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
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
[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/local
"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
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 aut
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?" An
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
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
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 o
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-li
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 arc
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 whe
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,
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
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
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 p
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.
H
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.
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 arch
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
>> >>
>> >>
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]
>
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. als
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 -
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]
> >
> 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
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 pa
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 debi
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-Relea
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-li
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
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
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.
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
> /
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 f
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).
Po
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 s
> 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
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 (im
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 matt
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
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
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
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
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-u
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/dp
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 multiar
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:
h
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.),
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,
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, dp
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
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.
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
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
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
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
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
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
61 matches
Mail list logo
