ckage in setup.py
or changing the .py files. I get no warning on building and I have to
create the patch manually.
Is this a regression or is there something different about the
json-schema-validator and versiontools packages?
This happened with 1.17.11 and 1.17.12.
--
Neil Wil
er information, will be in /var/lib/apt/lists/ - one large file per
apt source, combining installed and uninstalled packages.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
typically includes removing libfoo-dev:i386 and installing
libfoo2:armhf & libfoo-dev:armhf. libfoo2:armhf can, of course, stay
installed for later.)
MultiArch in Debian is principally concerned with runtime paths, the
build-time paths and consequent cross-compilation support still has a
few
;problem".
When calculating the shlibs of a package during the build, the libfoo
part of the dependency is not relevant, it is the libfoo?-dev package
which determines which .so symlink gets used and therefore which libfoo
gets linked.
This is a topic for the debian-dpkg list, please follow up there.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpa45NBs1Zd_.pgp
Description: PGP signature
to put any
> > more of it into dpkg.
>
> Except for my comments above, I tend to agree with this.
I'd be happy if this bug is closed with an upload of dpkg which extends
the cputable data to complete the ABI declarations with the
architecture-specific values from which dpkg-cross / replacement can
derive the cache values.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpgpoy3ZoYdp.pgp
Description: PGP signature
On Sun, 22 Jul 2012 18:01:05 +0100
Wookey wrote:
> +++ Neil Williams [2012-07-22 17:05 +0100]:
> > One unresolved issue is the cache values and architecture support:
> > where to put the cross- config settings currently implemented
> > in /etc/dpkg-cross/cross* which
to implement MultiArch support but
there remains the issues around MultiArch and -dev packages which may
yet require some dpkg support - and thereby block this bug.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp4TqfE903Ps.pgp
Description: PGP signature
mation at the point where it is unpacked.
Wherever the data lives inside the .deb is not the problem.
Where the data gets cached, copied, listed and parsed is likely to be a
major problem.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpRuL0mtyRmz.pgp
Description: PGP signature
onsole screen.
... because you aren't capturing STDERR
> PS: Im sending this email, as I am unable to find the bug tracker for the
> package directly =x
http://bugs.debian.org/dpkg
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpZbkfHtvvXo.pgp
Description: PGP signature
ing the old value
as another field. Reviewer doesn't really fit.
X-DebianBuilder: the Signer details from the original Debian package
X-DebianDate: the date the Debian package was signed.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgplB6NS2U8xt.pgp
Description: PGP signature
#x27;t work as expected. Don't hide (or
erase) useful stuff...someday, you'll regret that 'rm' when someone
files a bug...
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpLtrniMjq5I.pgp
Description: PGP signature
list of remaining conflicts are bugs and
the gzip bug doesn't matter anymore.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpDQTFHJxHrf.pgp
Description: PGP signature
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl wrote:
> On 07.02.2012 18:07, Joey Hess wrote:
> > Neil Williams wrote:
> >> I'd like to ask for some help with a bug which is tripping up my tests
> >> with the multiarch-aware dpkg from experimental - #647522 -
hroot/var/lib/dpkg/ between using dpkg --unpack (native
architecture) and the multistrap method (native or foreign).
Can we look again at a way of unpacking a .deb which is
architecture-neutral but still allows the package to be configured
once the fs is accessed under the appropriate arch?
--
osing the .pl suffix, so this is one way to work out which script is
being called.)
Therefore, as Guillem has already mentioned, this is more likely to be
down to your perl installation - if you set the correct path to perl
does dpkg then build?
What path do you need to specify to run any
ocessing by dpkg (and apt) so that the templates
are located correctly and either presented as package.templates or
handled as package-tdeb.templates.
I think we need a wiki page to try and sort these things out, we also
need to get together at DebConf. The DEP mechanism being broken, I'll
s
On Sat, 2 Apr 2011 05:47:47 +0200
Guillem Jover wrote:
Adding linaro people and debian-embedded to CC:
> Hi!
>
> On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote:
> > dpkg cannot be executed inside the chroot because it has not
> > necessarily been unpacked at thi
On Fri, 1 Apr 2011 22:31:07 +0100
Neil Williams wrote:
> Inside:
> /home/test# dpkg-query --control-path libc6 postinst
> /var/lib/dpkg/info/libc6:amd64.postinst
>
> /home/test# dpkg-query --admindir /var/lib/dpkg --control-path libc6 control
> /var/lib/dpkg/info/libc6:amd64
ame, then lookup Architecture in the same way,
add that to the filename of the created maintainer script etc.
for /path/to/chroot/var/lib/dpkg/info/*
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgp27291eH5tY.pgp
Description: PGP signature
On Mon, 21 Mar 2011 14:03:37 +0100
Matthias Klose wrote:
> On 21.03.2011 11:25, Neil Williams wrote:
> > The people who are most likely to be doing this now are Linaro.
> > Emdebian Crush stalled after Lenny (and used ARM not armel), so the
> > version of gcc-4.2 in Lenny sh
ulti-arch path is not needed... but I don't see why
> it should be treated differently than the cross-arch paths.
>
> Can you enlighten us?
For building a cross-compiler, Steve is correct - it doesn't matter.
For using that cross-compiler to cross-compile gcc itself, it will
ma
ckages that will be affected by the above problems?
> Please file a bug and usertag it with this command:
> $ bts user debian-dpkg@lists.debian.org . usertag $bug + multiarch
Done. #616111
Bug CC'd.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpEOZfL6En7b.pgp
Description: PGP signature
n cannot use dpkg --unpack and has to
have a separate method involving dpkg -x and dpkg -e.
'dpkg --unpack and dpkg --root foo --install' insist on trying to run
the prerm/preinst which is just wrong.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpU5hMBdq2hH.pgp
Description: PGP signature
urce code or information at Emdebian about debconf
settings:
http://www.emdebian.org/release/grip/a1106.html
http://www.emdebian.org/svn/browser/current/host/trunk/emdebian-rootfs/trunk/emdebian.crossd#L77
DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true
export DEBIAN_FRONTEND DEBCO
chitecture -a
setting environment variables?
The only problem that results from dpkg-architecture usage (AFAICT) is
that some maintainers have got the autotools-dev advice wrong and are
always setting --host as well as --build instead of just --build - that
can't be fixed in d
ging tools and that means dpkg and no dpkg-cross, it means apt
and no apt-cross and it means that cross-building needs to adopt and
modify multiarch to the point where we can all use it, albeit with
wrappers and support tools where necessary. Then, we can work on
absorbing those wrappers into the new
/usr/ -- so I
> don't think there is a pressing need to replicate a filesystem hierarchy
> standard below a triplet directory.
True, however, that is not a sufficient reason to not
move /usr/ to /usr/lib/ and /usr/include/
if it means getting such support into the core Debia
On Thu, 12 Mar 2009 16:00:26 +0200
Guillem Jover wrote:
> On Wed, 2009-03-11 at 12:13:47 +0000, Neil Williams wrote:
> > What I really need, in order to test properly, is a package that can
> > trigger install-info. I admit, I'm a bit unfamiliar with triggers still
> >
usr/arm-linux-gnu/[usr/]lib/libbla.so
> /usr/arm-linux-gnu/[usr/]include/foo.h
>
> or
>
> /lib/arm-linux-gnu/libfoo.so
> /usr/lib/arm-linux-gnu/libbla.so
> /usr/include/arm-linux-gnu/foo.h
>
> It has always been a question of where to put the tripplet, not
> whether or not to have an extra subdir below that. Although I'm
> against the subdirs. No need to duplicate that this is "usr".
I'd agree - [usr] below $arch-linux-gnu appears redundant to me. The
only difference between /lib and /usr/lib/ relates to the libraries
required to boot before /usr is mounted. That reasoning doesn't apply
to toolchain issues.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpJLHKAPC99k.pgp
Description: PGP signature
lib/libfoo.so
/usr/include/arm-linux-gnu/usr/include/foo.h
?
I thought the question was whether we would have:
/usr/lib/arm-linux-gnu/lib/libfoo.so
or
/usr/lib/arm-linux-gnu/usr/lib/libfoo.so
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
or the current
/usr/arm-linux-gnu/lib/libfoo.so
as a conversion of /usr/lib/libfoo.so
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp9tgMdTd7tZ.pgp
Description: PGP signature
mental texinfo
sources above?
Is it a case of:
1. create debian/install-info.triggers in the tex source above
2. create a modified coreutils (for testing in a chroot) where the info
document is part of the package, not mentioned in the maintainer
scripts
3. and?
--
Neil Williams
=
h
On Wed, 11 Mar 2009 10:30:12 +0100
Norbert Preining wrote:
> On Mi, 11 Mär 2009, Neil Williams wrote:
> > Is it meant to only echo the command out?
>
> Uups, forgot the comment out the part in the install-info.sh. please can
> you do so and retry. The very first lines ;-)
&g
document is removed, so if the
intention is that the postinst will become a no-op - merely echoing the
command - then this seems OK for what I need.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpDmlZoArq1r.pgp
Description: PGP signature
On Mon, 23 Feb 2009 22:46:24 +1030
Ron wrote:
> On Sun, Feb 22, 2009 at 12:23:22PM +0000, Neil Williams wrote:
> > > The rationale is, things like arm and uclibc have many possible variants,
> > > and we cannot possibly provide them all by default.
> >
> >
or this?
I can create a file in /etc/ that update-alternatives notices in order
to change behaviour, that seemed like the best initial approach.
(Doesn't have to be in /etc/ actually.)
Does update-alternatives need to fail noisily / die if the target of an
alternative does not exist? (thereb
On Fri, 20 Feb 2009 16:08:45 +1030
Ron wrote:
> On Thu, Feb 19, 2009 at 10:24:34AM +0000, Neil Williams wrote:
> > On Thu, 19 Feb 2009 08:47:47 +0200
> > Guillem Jover wrote:
> >
> > > > 3. Any renaming issues or other changes required in the current package?
&
ose agreed to include (at least agreed with
> the idea behind the patches).
>
> Once we have a working toolchain we can start drafting the details for
> the implementation in the packaging level, and we'll be able to test
> stuff easily. Although, there'
perl to C++.
If there is a desire for dpkg-cross functionality to be C rather than
perl, I can cope with that - depends what we want to achieve.
Where do we start?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co
had been raised a
year ago . . .
Try again in 6 months time?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpsG6hSq08mv.pgp
Description: PGP signature
e that there cannot be
any expectation that any help would be available within a specific
deadline. Everyone is a volunteer, no-one can say whether anyone will
be able to help you.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-
anges are now in
place. The changes for dpkg, by comparison, are small. In many ways,
the scope of the changes within dpkg are dwarfed by the scale of
changes required in the archive and elsewhere and those changes, as
I said above, are already agreed with the relevant teams.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp4SHTwP126A.pgp
Description: PGP signature
s
important to the overall usefulness of TDebs in general. Updates to the
TDeb then simply replace the previous TDeb, leaving the .dsc and the
rest of the (signed) Debian files completely unchanged. AFAICT it is
not possible to "patch" a binary debian package - you lose all the
bene
On Wed, 3 Dec 2008 09:12:46 +0100
Raphael Hertzog <[EMAIL PROTECTED]> wrote:
BTW, it was Eddy Petrisor, not Eric - typo. Sorry Eddy.
(Thanks, Christian.)
> On Tue, 02 Dec 2008, Neil Williams wrote:
> > > It is a very sizable special case, though, and growing thanks to
dpkg class alongside DEB_VENDOR to
provide more flexibility in how Debian packages are assembled.
I certainly want to have class support within tdebs (to make it easier
to remove translated manpages that are useless in Emdebian).
Right now, I'm concentrating on what changes are nec
rs should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.
>
>
able to enable hardening options by default and I agree with
> them that official support for such a facility is desirable.
>
> See also #498355 and #498380 for such requests from Emdebian.
Note also that Ubuntu are interested in supporting distribution-wide
build options.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
e code supporting alternatives - not my
favourite option when the entire OS has to fit into 32Mb (or 64Mb for a
full GUI using glibc).
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote:
> * Neil Williams
>
> | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
> | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
> | package under that, as we do with dpkg-
ng the
> > diversion is uninstalled as now you have conflicting packages.
> > Actually, you already had conflicting packages that just weren't
> > affected yet because of the diversion, which leads to 2).
If the multiarch package can be installed alongside the primary wit
ersion without the primary version, is
that something dpkg even needs to worry about? The default (to me)
should be to preserve the primary architecture and ensure that if the
multiarch package is purged, the primary architecture package is still
in a pristine state. Allowi
On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote:
> Can you give me an url for Tollefs work? Maybe that can be used to
> rename by default.
See this thread in the dpkg list archives:
Try this one instead:
http://lists.debian.org/debian-dpkg/2008/01/msg00011.html
--
debian-dpkg/2008/01/msg1.html
And some other links for background:
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/25-dpkg-filtering.html
http://www.emdebian.org/docs/howto-4.html
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
>
> >> If you run autotools at build time you should also ensure that the
> >> changes which autotools ma
from maintainer scripts, I still need to have a
useless /usr/bin/install-info containing #!/bin/sh - it would be nice to
not require such a hack, merely to dump documentation.
> Another feature that would be very desirable is triggers support. In
> the long run, install-info should pr
uld be all you need. No config.site.
> What should I add to the ostable, triplettable, and cputable files to get
> rid of the above warnings?
Nothing. The warnings, AFAICT are correct, your original approach seems
wrong.
--
Neil Williams <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
ke distcheck' is abandoned, there will simply be no guarantee
that dpkg will ever build *except* within the limited environment of a
Debian buildd.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpJqK1wxfzuw.pgp
Description: PGP signature
proc none /mnt/hda/proc
> chroot /mnt/hda /bin/bash -c 'apt-get install portmap'
chroot /mnt/hda apt-get install portmap
You shouldn't need the extra shell.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.
ve any problem in getting rid
> > of debian-dpkg-bugs, though.
>
> Is anyone reading [EMAIL PROTECTED] here that would be bothered if they
> received
> the BTS mails related to dpkg ?
I'd support having BTS email on this list.
--
Neil Williams
=
http://ww
only cares
about what is Essential to the current device.
I can envisage testing for package splits by filtering out certain
package components during install, seeing which applications actually
need those components and thereby devising a new package split that
operates on a *f
ge GNU/Linux box that did away with
some kind of find functionality.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpCHCC6KTtZ4.pgp
Description: PGP signature
Raphael Hertzog wrote:
> On Tue, 28 Aug 2007, Neil Williams wrote:
>> As outlined on the debian-dpkg lists, I've been testing the removal of
>> the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during
>> the rewrite of dpkg-cross and I now have two
# (awaiting fix for 439979)
$ dpkg-buildpackage -aarm
dpkg-buildpackage: source package hostname
dpkg-buildpackage: source version 2.94em1
dpkg-buildpackage: source changed by Neil Williams <[EMAIL PROTECTED]>
dpkg-architecture: warning: Specified GNU system type arm-linux-gnu does
not mat
g scratchbox2, ask on the debian-embedded
mailing list (where you'll find the scratchbox2 maintainer, me and
various other cross-building types).
Whatever you want, this problem is *not* in dpkg and there isn't any
point continuing this thread here.
--
Neil Williams
=
ian --> libgtk-directfb-2.0-0 (/usr/local/) ==> clock (dpkg install)
(where --> represents building the upstream source directly and
==> represents installing a Debian package.)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpZFowrPnrww.pgp
Description: PGP signature
g useful with
dpkg-buildpackage won't have a problem running perl.
> I can do most of the packaging stuff with shell and
> sed.
I can do *all* of the packaging stuff with Perl and CPAN. Last time I
checked, neither you nor I are dpkg maintainers / uploaders so let's
just work wit
On Sun, 23 Sep 2007 13:56:24 +0200
Frank Lichtenheld <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
> > The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
> > +2.0.0pre2 which is due to be uploaded to experim
On Mon, 27 Aug 2007 14:26:07 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:
> OK, I now have two patches (and a dummy changelog patch that just acts
> to separate these changes from the existing dpkg packages) attached. I
> also have maintainer script changes that remove any prev
called during a cross-build - i.e. only when
the -a option is supplied to dpkg-buildpackage.
With dpkg-cross pre2, the diversions are gone for good.
;-)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--- dpkg-1.14
.
This will be in dpkg-cross 1.99+2.0.0pre2 (experimental) - although
pre1 is yet to leave NEW. :-(
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
--
Neil Williams
=
http://www.data-freedom.org/
http://
#x27;win32-i386' => 'i386-cygwin'
);
dpkg-architecture values:
armeb => armeb-linux-gnu
hurd-i386 => i486-gnu
s390x => s390x-linux-gnu
openbsd-i386 => i486-openbsd
freebas-i386 => i486-freebsd
darwinbsd-i386 is unknown to dpkg-architecture
win32-i386 is unknown to dpk
On Thu, 23 Aug 2007 21:21:57 +0100
Neil Williams <[EMAIL PROTECTED]> wrote:
> On Thu, 23 Aug 2007 05:52:01 +0300
> Guillem Jover <[EMAIL PROTECTED]> wrote:
>
> > > So far, pre1 is largely complete for dpkg-cross and the
> > > dpkg-buildpackage diversion
erts dpkg-buildpackage and dpkg-shlibdeps.
> This is clearly less than ideal. dpkg-dev having cross support
> built-in seems sensible to me. Especially if it only makes dpkg a few
> K bigger.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp2MLQeAenRP.pgp
Description: PGP signature
72 matches
Mail list logo
