imental
then
sbuild -d experimental -c unstable-amd64-sbuild
and that worked without lintian complaining, and produced a package with a
changes file that will send it to experimental.
HTH
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
'm not sure if I'm posting this message in the right channel, sorry.
You have indeed found the right place to ask questions like this, (and
more detailed ones). So that's a good start :-)
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
nstances.
You can do both at once but I find it easier if the libraries go in first,
then you can be sure everything works without having to have 'special'
build environment with your extra library packages present.
Mostly it depends how fast you want to move. Either is fine.
Wookey
--
Doxyfile.orig Doxyfile
-mv libsquish.pc.in.orig libsquish.pc.in
dh_clean
Does that help?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
-tools and ssh-toolz is, so at least be
very clear in the long description, and give a clue in the short one
if possible.
And thanks for thinking about it before it's too late to fix. Names that
are clear to users are definitely helpful.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
We are working on unbunging things
so we can get back to our usual level of smooth updates soon. I expect
unstable to be rather more unstable than usual for another week or
two.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
sorts of dependency, nor packages furtuer down the tree.
I hope that answers your question?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
), but could be any README, or
even just a notice on the project website, or an email saying '
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
in, and you don't need to worry
too much, but it is a good idea to at least have this stuff in the
back of your mind when packaging. Ideally this would all work
correctly on the whole archive, and packagers are the ones best-placed
to stick in the necessary runes.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ld is a different thing, and
whilst it would be good to have that working too, it won't be used by
the buildds.
I had a quick go with a trivial packaging and yes it didn't build on x86
/usr/bin/c++ -I/home/wookey/packages/oaknut/debian/oaknut-1.2.2/tests
-I/home/wookey/packages
than your made-up dates (which it won't be if you
used the obvious '20231118' (version 20-million-ish)).
So you need to version it like this:
0~20231118
0~20240315
etc
This is in the debian docs somewhere, but I forget where.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
int stash collection.
It's not personal.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
86_64'
None of this has anything to do with your actual lintian error, as you have
worked out :-)
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2023-11-10 23:44 +0100, Preuße, Hilmar wrote:
> On 10.11.2023 03:10, Wookey wrote:
>
> Hi Wookey,
>
> > I think your options are
> > 1) add an epoch (which exists to deal with this sort of problem)
> >
> Well, would like to avoid it, if possible.
There is n
with the old version until a higher-versioned
one appears
3) upload a 'nobbled' version number, which is often done to deal
with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?
I'd probably go
On 2023-10-31 04:57 +, Phil Wyett wrote:
> On Tue, 2023-10-31 at 04:23 +0000, Wookey wrote:
> > uscan is doing something very strange with version numbers and I
> > don't understand what's going on.
> >
> > However, whilst it now finds the current v3.5.0 i
gz
uscan debug: line: get_newfile_base()
uscan info: Matching target for filenamemangle:
https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz
uscan debug: safe_replace
input="https://github.com/Mbed-TLS/mbedtls/archive/refs/tags/v3.5.0.tar.gz";
uscan debug: safe_
can do it for you (I use and enjoy this package).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ully (finally) get this fixed for the general case. I can
provide debian packaging and build expertise to complement your
knowledge of google-apis. (and then maybe we can give
bazel-remote-apis a very similar treatment).
I will put my unfinished project on salsa, file an ITP, and find my
notes, the
. I'm fairly sure there is some
actual policy written down somewhere, probably in the 'DD/DM
application process' info.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2022-11-01 08:57 +0500, Akbarkhon Variskhanov wrote:
> On Mon, Oct 31, 2022 at 7:02 PM Wookey wrote:
> > The description could be more useful.
> > "The plugin supports common mathematical operators (+, -, *, /, ^) with
> > usual
> > precedence rules, and som
to the copyright list
and the package includes the LGPL COPYING.LIB at top level, although it's not
obvious if that actually applies to any of the code.
If it does then the LGPL should be listed (maybe you already checked this?).
Otherwise it looks fine.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Just put 3rdparty into files-excluded: in the debian/copyright file, and setup
up the watch file to repack/rename.
https://wiki.debian.org/Javascript/Repacking
https://wiki.debian.org/UscanEnhancements
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
/usr/share/javascript) is used
(referred-to as http://localhost/javascript/)
If that version is too old then investigate if it can be updated (without
breaking other depending packages)
If the package is not yet present then ideally package that too.
Info here: https://wiki.debian.org/Javascript
W
ut do people really need both packages in the archive? Or is only the pkgB
actually useful?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ducing
pkg-A and one producing pkg-B, so that both end up in the
archive. Binutils is an example of a package that does this (building
both native and cross versions).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
out you mark which arches to run
tests on separately from which arches to build.
If the package is available then maybe someone who cares will fix
it. If it isn't they probably won't even try. A note in the
Debian.README about this known issue would be helpful.
Wookey
--
Pr
php?p=easygen vs.
> https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser
This is not cross-building. This is native building. Cross-building is
building one package on a machine of another architecture.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2022-01-08 16:54 +0100, Andrea Pappacoda wrote:
>
> Il giorno sab 8 gen 2022 alle 01:52:47 +, Wookey
> ha scritto:
> > However, I have already packaged v3.0.0. It's not been uploaded yet
> > because it fails some tests intermittently, and I am in discussion
&
iving them a prod and us waiting another week or so
to see if v3.0.0 will happen?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
org/debian/flam3.git
> <https://salsa.debian.org/debian/flam3.git>
Hmm, last touched 3 years ago. A long way behind the package.
Done.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ian to have a big patch.
Versioning could be tricky in some situations, but SFACT the ofono
mmsd is just 0.0 so the debian version can be 0.0.something and remain
compatible with a shift back to that repo at some point.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ed to get the migration going and allow others to test. I
should be able to contrive a non-headless armhf machine too, given a
bit of time (not today)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
y
the watch file to do the renaming. Details are described here:
https://wiki.debian.org/Javascript/Repacking
i.e don't just manually delete the dir and then call that file 'orig'
because it's not the original source tarball/git checkout (even though
it should be if th
hich case you need to get thosepatches into the
debian package, or stick with the 3rd-party version. Or it requires a
different version from the one(s) available in debian inwhich case
agin you either need to fix it to work with the version in debian or
stick with the 3rd-party version.
Does that
or ignored?
The config file has not changed from what is in the current version and the
file _does_ seem to specify a send_destination, so is there in fact a lintian
bug?
http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
(which can take
a while (days to months) after initial upload).
https://wiki.debian.org/BuildingFormalBackports
https://wiki.debian.org/Backports
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
nse for something
like a big GUI toolkit: QT4 and QT5, but not a leaf compression library)
Library naming conventions are subtle and the reasons for _why_ one
might want to do one thing or another are not obvious.
Details are given in policy:
https://www.debian.org/doc/debian-policy/ch-sharedlibs
e in debian is always sid (unstable).
The sbuild-debian-developer-setup package provides a very convenient
way to set this up if you haven't already.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2020-04-22 15:13 -0400, Aaron Boxer wrote:
>
>
> Thanks a lot, Wookey! I think I will just change my library name. At this
> stage, no other libraries
> that I'm aware of are relying on the name.
Right. If you are upstream and can do this, then yes just picking a
non-
ng to do depends on the popularity and satbility of these
projects and how many other packages/external projects use
them. Contacting the grok maintainer to discuss what would be best is
in order IMHO
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ted to reliably build every package using sbuild had
an automated way of doing it.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
be
> fulfilled. However I know that the packages in question do exist for
> that arch. What am I missing?
It's because libc6 is out of date on sparc64 compared to amd64 (the arch I
assume you are building on)
(unstable-amd64-clean-home)wookey@e110476-lin:~$apt policy libc6-dev:sp
recently?
He's been discussing stuff on debian devel this week, using Daniel Schepler
So yes, he's active and around.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
quietly
throws away your packages without telling you.
I know this because I've had this problem for some time (my machine
defaults to using the wrong key despite having default-key set in
.gnupg/gpg.conf so I have to sign with an expicit key (debsign -k)).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
e no longer
supporting something that only has '8'.
> And should the compat file be 11 in all cases?
No, the compat file should match the dependency, and determines the
actual behaviour of debhelper in the packaging. i.e. that's the
important bit, and the control file depen
x27;wine' binary that was 32 or 64
as required then you could make this work as you want. Otherwise you
need both those packages to depend on another wine-startup or whatever
that contains the shared file.
(I think - I admit I haven't fully groked the wine package layout)
Wookey
--
Princip
;ll do for now. not-quite finished package is here:
http://wookware.org/files/bankofcucc/
Cheers for any clues.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
lowed
by a long argument about whether or not it meets the DFSG - this is a
very foolish route to take without a _really_ good reason), and write
it down.
Once they've declared a free licence, Debian is happy. How they choose
to record their authorship copyrights is entirely up to them - just
On 2018-12-07 17:06 -0800, John Horigan wrote:
> On Fri, Dec 7, 2018 at 8:36 AM Wookey wrote:
> On 2018-12-07 08:27 -0800, John Horigan wrote:
> Normally the library package
> libfoo is shared, and the libfoo-dev package contains the static
> version. You already
deal with -DEV packages and shared libraries? What am I
> supposed
> to do?
I can help explain this in more detail (as I've been doing a lot of
this recently, and I agree it's confusing), but lets sort out whether
you really need libagg-dev _and_ libagg2-dev first. I
ved files.
> So, after more than a year, I think he won't answer. So I have to come
> up with another solution. I just don't have an idea, what is the best
> way to do that. Can you help me?
Repacking the source without it is probably neatest. But just
removing it in the clea
s
tells me that 16.0-3 is less than 16.0.0-1 so that should work. This
seems like the best plan, but I wondered if there was anything
niftier?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
elf-contained, but clearly we'd like things to work as well as
possible for the cases where they aren't/can't be.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2017-10-27 12:12 +, Hugh McMaster wrote:
> Hi Wookey,
>
> Apologies for the delayed response.
>
> On Thursday, 26 October 2017 12:23 AM, Wookey wrote:
> >> The header was previously installed with other headers in
> >> /usr/include/.
> >>
DEB_HOST_MULTIARCH} gets substituted.
But I'd check whether you really need to do that first.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
ou do one with neon
enabled for armhf, or altivec for powerpc. It's much better to build
one version for each arch that can dynamically use available HWCAPS,
but of course that's tricky if upstream doesn't support it.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http:
arballs and put them into their binary tarballs/packages. If they
> refuse, then add Files-Excluded to debian/watch
Files-Excluded goes in debian/copyright, not debian/watch. (unless
there is some new feature I'm not aware of). It would arguably make more sense
in watch, but that's n
runtime function/library level detection in the future if you did
that. You definitely don't want 15 flavours though. Work out which
ones _really_ matter (> 10% speed difference overall?) and package
those, perhaps.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2017-05-10 18:01 +0200, Kay F. Jahnke wrote:
> @pabs
>
> @wookey
>
> > There is (as yet) no mechanism in packing to select packages by
> > hardware variant or optimisation. It has been mooted, and could be
> > done, but it's a big job, which would take ye
On 2017-05-10 13:56 +0200, Christian Seiler wrote:
> On 05/10/2017 11:52 AM, Wookey wrote:
> > Debian requires packages to run on the base level ISA defined for each
> > architecture (which does change slowly over time).
>
> Well, kind of. What Debian requires is that if
so there is probably
some code already available for the checks and switching in your
language. For arm there is the ne10 package for useful optimised neon
functions, but it doesn't help with any other architectures, or the
fallback/variant-switching part, but it may still be helpful.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
rs from different conributors, even if they have the same
licence). But this level of detail is not required.
Even if you put it as one stanza because it's all one licence, it's
good practice to include all the authors names (that have indicated
their copyright by putting their names o
ontrol < control
#nasty hack for arch support - fixme!
ARCH1=armhf
ARCH2=arm64
mkpkg t62x fbdev ${ARCH1} ${ARCH2}
#mkpkg t62x wayland ${ARCH1} ${ARCH2}
#mkpkg t62x x11 ${ARCH1} ${ARCH2}
ARCH=arm64
mkpkg t62x wayland-fbdev ${ARCH}
mkpkg t62x fbdev-wayland ${ARCH}
ARCH=armhf
mkpkg t60x fbdev ${ARCH}
mkpkg t60x x11 ${ARCH}
mkpkg t62x wayland ${ARCH}
mkpkg t62x x11 ${ARCH}
mkpkg t76x fbdev ${ARCH}
mkpkg t76x x11 ${ARCH}
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
default
# choose gcc as if clang is installed too you have to pick one
qbs config profiles.default.baseProfile gcc
override_dh_auto_build:
qbs build -f dewalls.qbs profile:default
override_dh_clean:
# tidy up qbs profile builddirs
qbs clean profile:defa
guess maybe
you have a permissions problem?
You may also find that --log-external-command-output and
--log-external-command-error
will help.
--debug will give you buckloads of output, which again may help clarify the
issue.
I think there is a way to stop it putting i the <>
substi
ural choice for a
> tool
> that does the opposite of what sbuild-createchroot does.
'destroy' is closest to the opposite of 'create'. But 'remove' sounds
a bit less cataclysmic :-) Either will do fine.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
if you _really_ can't be bothered making man pages,
just leave it as upstream supplied. Using help2man is a worse
'solution' than doing nothing.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
e a man page.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
, debile or rebuildd can help you with this,
but they all need a bit of config to set up your chroots (suite, arch
etc), and a list of packages to build.
build-rdeps (from devscripts) is handy for listing all the packages
you want. (or dctrl-tools if you want to do fancier things).
Wookey
--
Pri
+++ Jakub Wilk [2016-04-10 17:15 +0200]:
> * Wookey , 2016-04-10, 15:49:
> >>nmh installs it's binaries (~20) into /usr/bin/nmh.
>
> Actually it installs to /usr/bin/mh, ...
>
> >>Now I try to do the same, and install mmh's binaries into /usr/bin/mmh,
>
ble to me.
> And what to do with man pages?
> For example, both provides `scan(1)', but only `nmh' has `mhshow(1)'.
Well, if you only install one or the other this isn't a problem - they both
just provide
a suitable set of manpages.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
+++ Mattia Rizzolo [2016-03-27 12:39 +]:
> On Sun, Mar 27, 2016 at 12:21:33PM +0100, Wookey wrote:
> > +++ Christopher Baines [2016-03-27 10:49 +0100]:
> > > On 20/03/16 03:12, Mattia Rizzolo wrote:
> > > A possible alternative would be to include a manpage made w
thus best avoided if
possible. Adding support for a 'nodocs' profile to skip its use is one
way to (mostly) deal with that.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Bdfsg-1
(which then cause another (wrong) lintian warning about the GPL as
that is mentioned in the text)
That text came from the bottom of http://tango.freedesktop.org/
Can you find a similar statement for your project?
HTH
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
is no longer needed. It was a transitionary measure for
upgrading from squeeze.
Adding the "Multi-Arch: same" field to libraries (and making them install in
the arch-specific localtions) is good.
So yes, apply doko's patch, and just remove the Pre-Depends: line as it is no
lo
nd cmake (and are built from git with git-buildpackage)
http://anonscm.debian.org/cgit/debian-science/packages/ros
It works fine, although you do need to use
dpkg-source --after-build .
to tidy up build artifacts before doing clean builds in sbuild for some
packages.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
ound about mentoring 'via private
email' possibly meant to refer to the contact being by private mail,
not to the asking and answering of queries, although I agree it could
be read either way.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
oting in a
debian/README.source on how you do updates/new releases (especially
for anyone else that takes over in future or has to update/build it
locally for other reasons)
> Again, thanks for your support. Of course, I hope, i won't disappoint any of
> you guys :D
Don't worry.
+++ Andreas Tille [2016-01-04 16:19 +0100]:
> On Mon, Jan 04, 2016 at 03:07:40PM +0000, Wookey wrote:
> > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter
> > > /usr/lib/x86_64-linux-gnu/n> > The brute force way to fix this is to use
> > >
er is to stop it being generated with
CMAKE: SKIP_BUILD_RPATH TRUE
autotools: See https://wiki.debian.org/RpathIssue for details
(that whole page is useful - but maybe you read it and tried that stuff
already?)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
ither someone
noticed or you found a comms channel.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
7; too - that's just as anspect of makig it work nicely.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
ot; handles the cmake configuration and the
> "make" + "make install" step, and then passes the installed files to
> debian tools. I would like "dh" to configure, make and ask cmake to
> generate the packages directly (without any "make install").
people can at least see
what is going on. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757768
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
+++ Wookey [2015-10-03 14:05 +0100]:
> +++ Gudjon I. Gudjonsson [2015-10-03 13:48 +0200]:
> > Changes since the last upload:
> >
> > * New upstream release (Closes: #789831)
> > * Improve manpages as and sdcc
> > * Add manpages sdar, sdas3
csim to sdcc
> * Add binary file sdldstm8 to sdcc
> * Add provides c-compiler to control file (Closes: #768307)
> * Add huge memory model libraries (Closes: #768307)
> * Add deoendency on graphicsmagick-imagemagick-compat
> * Exclude example code from compression
Wookey
about derivatives upgrading from Ubuntu LTS for example,
where presuambly this will apply for some time yet.)
Should we in fact be advising removal of this stanza entirely now?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
> (4) it would probably be helpful to other X32 developers to ensure the
> new GDB is built and made available.
Prepare a patch so that it is easy for the maintainer to apply it and upload.
File it in the bug.
Then just wait till the maintainer uploads a new version with your
patch.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
should just be arch all IMHO, whatever actual
limitations there are in the wrapped linuxbrew. Then if someone makes
linuxbrew more capable one day this wrapper will at leastbe available
on all arches already.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
fix if you get errors.
So it is good practice for a package to be autoreconfable as that
means that it will build on more architectures, and new architectures
correctly. But if you cannot easily fix it this is not a reason to
delay upload (but you should probably tell upstream that their
ne with some python-clue could perhaps take a look (and would be
a better sponsor in that regard)
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trou
zog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
Not really since it also fails on arm64 with the same error.
adding -m64 on arm64 to a gcc invocation will result in an error
because it is meaningless. In general we should (IMHO) simply not be
using -m32 or -m64 in debian builds.
Not sure if I have understood you properly there? Maybe there is s
ht, so that DEB_BUILD_OPTIONS=nocheck works, which is often
important for cross-building.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
27;any'. It would have been useful to cc the sponsor who disgrees on
this mail so we can hear if there is some good reason why 'any' is in
fact not appropriate.
I suggest you file a debian bug with this patch, so that any necessary
debate will be recorded there.
Wookey
--
Princip
st one is out
of NEW, because there is a quite a high risk of something like the
above happening, which is not a big deal, just a bit annoying.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
w
+++ Wookey [2014-12-12 21:49 +]:
> +++ Tong Sun [2014-12-12 09:52 -0500]:
> > Dear mentors,
> >
> > I'd like to bring your attention again to dbab,
> Other than that it looks simple enough
Oh, and a man page would be nice.
Wookey
--
Principal hats: Linar
trm.
* There should be a systemd service file as well as an init script
* Any reason why dh compat level is 8 not 9?
* The package has a .pc dir but there is no patch series
Other than that it looks simple enough
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.o
'having somewhere public for others to
download from' or the 'building other arches natively' issues.
I have looked at this issue a few times and would love to have more
time to spend to spend on it...
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.or
1 - 100 of 143 matches
Mail list logo
