Re: RFC: 3.0 (git), now with bundles
Hi, On Wed, 02 Jun 2010, Joey Hess wrote: > Attached updated patch adds the ability to limit the history depth that > is included in the git bundle (via --git-depth), as well as fully > control which tags/branches/objects are included/excluded in the bundle > (via --git-ref). I've committed your patch with a few cleanups (coding style mainly) and will push it later today. It will thus be in the next upload (1.15.8). Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100725145914.ga5...@rivendell
Re: dpkg-buildflags
Hi, On Mon, 07 Jun 2010, Raphael Hertzog wrote: > > * If packages should set all the flags, have you considered having a > > mode where it lists them all (like dpkg-architecture -l), perhaps > > with export statements? > > Would you like this? I have no problem adding this feature to > dpkg-buildflags. I have added such a feature here, I will push it later today, it will be in dpkg 1.15.8. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100725150024.gb5...@rivendell
Re: Multiarch and ABI support
Dear Steve,
2010/7/24, Steve Langasek :
> On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
>> 2010/7/18 Steve Langasek :
>> AFAICS `dpkg' relais on -dumpmachine from `gcc'
>> scripts/Dpkg/Arch.pm:68:my $gcc_host_gnu_type = `\${CC:-gcc}
>> -dumpmachine`;
> It wouldn't. I don't see a compelling reason for dpkg to do this at all.
> Your quote shows that dpkg *does* do this today, which I didn't remember
> before this conversation, but that's not an explanation for *why* it does -
> as opposed to dpkg directly recording what its current architecture is.
I am not `dpkg' maintainer, nor I did such change, so *why* it does
that I do not know, but surely there is a reason which stands valid or
it is outdated.
> Calling this something other than "architecture" ("ABI", "subarch", etc) is
> quite beside the point - we still need a distinct name for any files we
> intend to ship in the main archive.
Yes, I agree, something that won't get easily outdated should work, or
even better relocatable (non-hardcoded) names would be best. You are
probably aware all changes this means for Debian infrastructure.
>> As I had stated previously my though on another thread [2], there are
>> two different cases mixed on `multiarch':
>> a) Co-installing libraries (in x86 world, with compatible ABI) which
>> main purpose it is to be able to run `non-free' software.
>> b) Co-building, which it is the part that affects me the most and can
>> be easily solved using sysroot switch on GCC, without any upstream
>> changes.
>> Using sysroot approach you might be able to co-install foreign (other
>> arches) libraries into the sysroot for case a) - it even lets the user
>> have multiple systems with same ABI and architecture, but with
>> different libraries (in the case you want to cross build non Debian
>> systems).
> sysroot is irrelevant to what multiarch aims to achieve.
Sorry, I think I have not yet understand you. Would you mind to expand
your point here?
While sysroot is just a tool which it is probably very helpful on
multiarch design. What is orthogonal on sysroot and multiarch are the
hardcoded paths (/usr/lib/) which we had discussed above that
are wrong.
Sysroot is everybody's way to cross compile in world but us (Debian)
if multiarch aims to be a fit-all solution it should be relevant, if
it is not, either you might misunderstood sysroot rationale or I just
should be stop loosing time on multiarch. Maybe multiarch just needs
to setup sysroot=/ and change FHS for upstreams to follow, which it is
not something it happens in couple months.
Kind regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinroaocjj7jgvhejphca07jydauhyyzr3s...@mail.gmail.com
[PATCH] add missing paragraph break to man page
--- man/dpkg-source.1 |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/man/dpkg-source.1 b/man/dpkg-source.1 index ac3ff82..3d87bc5 100644 --- a/man/dpkg-source.1 +++ b/man/dpkg-source.1 @@ -587,6 +587,7 @@ include. It may also be any parameter that can be passed to the master branch, use \-\-git\-ref=master. To include all tags and branches, except for the private branch, use \-\-git\-ref=\-\-all \-\-git\-ref=^private +.TP .BI \-\-git\-depth= number Creates a shallow clone with a history truncated to the specified number of revisions. -- 1.7.1 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100725181746.ga21...@gnu.kitenet.net
[PATCH] fix path to gitshallow file
It was looking in the current directory, which works most of the time,
but not always.
---
scripts/Dpkg/Source/Package/V3/git.pm |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/Dpkg/Source/Package/V3/git.pm
b/scripts/Dpkg/Source/Package/V3/git.pm
index c7429c1..de80b4e 100644
--- a/scripts/Dpkg/Source/Package/V3/git.pm
+++ b/scripts/Dpkg/Source/Package/V3/git.pm
@@ -225,7 +225,7 @@ sub do_extract {
# Move shallow info file into place, so git does not
# try to follow parents of shallow refs.
info(_g("setting up shallow clone"));
-system("cp", "-f", $shallow, "$newdirectory/.git/shallow");
+system("cp", "-f", $dscdir.$shallow, "$newdirectory/.git/shallow");
$? && subprocerr("cp");
}
--
1.7.1
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100725182041.ga21...@gnu.kitenet.net
Re: Multiarch and ABI support
Hello Loïc,
2010/7/25, Loïc Minier :
> On Sun, Jul 25, 2010, Hector Oron wrote:
>> Sysroot is everybody's way to cross compile in world but us (Debian)
>> if multiarch aims to be a fit-all solution it should be relevant, if
>> it is not, either you might misunderstood sysroot rationale or I just
>> should be stop loosing time on multiarch. Maybe multiarch just needs
>> to setup sysroot=/ and change FHS for upstreams to follow, which it is
>> not something it happens in couple months.
a couple of months... to my concern for "Squeeze release".
> Cross-compiling with the current sysroot implementation does not allow
> picking up libs and headers from FHS or multiarch pathnames, e.g. if I
> create an armel chroot, I can't point my cross-compiler at it and have
> it pick up target headers/libs from there, even with sysroot.
That depends very much on the path layout. For sysroot paths would be:
${SYSROOT}/usr/lib
${SYSROOT}/usr/include
where ${SYSROOT} can be anything and it is relocatable.
Surely, FHS needs to be revisited for multiple architecture support,
they unhelpfully picked up /lib64 by the time they discussed this
issue.
To have multiarch paths,
/usr/lib/$triplet
/usr/include/$triplet
where $triplet is Debian triplet or any new name it comes up from ABI,
subarches support.
Surely you can patch FSF GCC or/and other compilers to support that a
approach and still does not affect sysroot (just add ${SYSROOT} as
prefix), but that decission is not to be taken on a Debian forum, but
on FHS forums. IMO nothing we can do before releasing Squeeze.
> Using Debian as a build environment with a cross-compiler and sysroot
> to generate a target rootfs is fine, but it's not very well suited for
> generating a target Debian rootfs.
Do you mind to expand why is not well suited for generating a target
Debian rootfs?
In your opinion, what should we ship as cross compiling framework for
Squeeze release?
Kind regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlkti=bz7y+zq0s0ocvoseqns2obte7rmxfvjj1b...@mail.gmail.com
Re: [PATCH] add missing paragraph break to man page
Hi, On Sun, 25 Jul 2010, Joey Hess wrote: > man/dpkg-source.1 |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) On Sun, 25 Jul 2010, Joey Hess wrote: > It was looking in the current directory, which works most of the time, > but not always. > --- > scripts/Dpkg/Source/Package/V3/git.pm |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Both patches applied, thanks. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100725192929.gb21...@rivendell
Re: Multiarch and ABI support
Hector Oron writes:
> Dear Steve,
>
> 2010/7/24, Steve Langasek :
>> On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
>>> 2010/7/18 Steve Langasek :
>
>>> AFAICS `dpkg' relais on -dumpmachine from `gcc'
>>> scripts/Dpkg/Arch.pm:68:my $gcc_host_gnu_type = `\${CC:-gcc}
>>> -dumpmachine`;
>
>> It wouldn't. I don't see a compelling reason for dpkg to do this at all.
>> Your quote shows that dpkg *does* do this today, which I didn't remember
>> before this conversation, but that's not an explanation for *why* it does -
>> as opposed to dpkg directly recording what its current architecture is.
>
> I am not `dpkg' maintainer, nor I did such change, so *why* it does
> that I do not know, but surely there is a reason which stands valid or
> it is outdated.
Compiling dpkg on a system that has no dpkg. No dpkg-architecture to get
the current architecture from.
>>> Using sysroot approach you might be able to co-install foreign (other
>>> arches) libraries into the sysroot for case a) - it even lets the user
>>> have multiple systems with same ABI and architecture, but with
>>> different libraries (in the case you want to cross build non Debian
>>> systems).
>
>> sysroot is irrelevant to what multiarch aims to achieve.
>
> Sorry, I think I have not yet understand you. Would you mind to expand
> your point here?
>
> While sysroot is just a tool which it is probably very helpful on
> multiarch design. What is orthogonal on sysroot and multiarch are the
> hardcoded paths (/usr/lib/) which we had discussed above that
> are wrong.
/sysroot/usr/lib/ is the normal directory.
/sysroot/usr/lib/ is the multiarch directory under a sysroot
Are you thinking of the special case of multiarch with sysroot=/?
What is wrong with the path is that the triplet is not unique and
sometimes differs when it shouldn't. So instead of the triplet use a
different string that uniquely identifies the abi. In the past the
triplet has just been the standard for that.
Could I suggest dpkg-architecture -qDEB_HOST_ABI? The string should only
be hardcoded in one single spot.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3ubuv1b@frosties.localdomain
Re: Multiarch and ABI support
Hi Goswin, >>> It wouldn't. I don't see a compelling reason for dpkg to do this at all. >>> Your quote shows that dpkg *does* do this today, which I didn't remember >>> before this conversation, but that's not an explanation for *why* it does >>> - >>> as opposed to dpkg directly recording what its current architecture is. >> >> I am not `dpkg' maintainer, nor I did such change, so *why* it does >> that I do not know, but surely there is a reason which stands valid or >> it is outdated. > > Compiling dpkg on a system that has no dpkg. No dpkg-architecture to get > the current architecture from. Sounds like a reason. Thanks. > /sysroot/usr/lib/ is the normal directory. > /sysroot/usr/lib/ is the multiarch directory under a sysroot > > Are you thinking of the special case of multiarch with sysroot=/? Yes, I was thinking that but later I realized that does not fit. Where do you place cross built binaries? It could work as build this armel binary and upload it to target device, but it will not work for cross building a small rootfs (uclibc+busybox) with in host system and then export it to target device or roll a tarball. > What is wrong with the path is that the triplet is not unique and > sometimes differs when it shouldn't. So instead of the triplet use a > different string that uniquely identifies the abi. In the past the > triplet has just been the standard for that. > > Could I suggest dpkg-architecture -qDEB_HOST_ABI? The string should only > be hardcoded in one single spot. I think there is yet another proposal waiting on the pipeline to be proposed publicly. Cheers, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim+dx9xrjzopv9x9f=_i0y+4a8xg6k+fbaei...@mail.gmail.com
Re: Multiarch and ABI support
On Sat, 24 Jul 2010, Steve Langasek wrote:
> On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
>
> > 2010/7/18 Steve Langasek :
> > > I'm puzzled why dpkg needs a unique triplet for a port. dpkg needs to map
> > > port names to triplets, but why does it need to do the inverse? And if it
> > > doesn't need to map triplet->port, why would the triplet need to be
> > > unique?
>
> > AFAICS `dpkg' relais on -dumpmachine from `gcc'
> > scripts/Dpkg/Arch.pm:68:my $gcc_host_gnu_type = `\${CC:-gcc}
> > -dumpmachine`;
>
> > Then all the magic starts...
> > How would `dpkg' can then map GCC tuplets into Debian triplets being
> > the same with different Debian architecture names?
>
> It wouldn't. I don't see a compelling reason for dpkg to do this at all.
> Your quote shows that dpkg *does* do this today, which I didn't remember
> before this conversation, but that's not an explanation for *why* it does -
> as opposed to dpkg directly recording what its current architecture is.
I don't know if you're all on the same page, but the pasted snippet is
from dpkg-dev and not from dpkg, so it's used at package build time only.
dpkg does record its current architecture in the dpkg binary itself and
gives it back when you do “dpkg --print-architecture”.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100726055825.gd26...@rivendell
