It defaults to 1GB; you can change this in a D hook script, e.g. save
this as ${HOOKDIR}/D07largerccache and set execute permission:
#!/bin/sh
ccache -M 20G
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
sbuild also has lots of nifty extra features. One I use a lot is the ability
to locally build a stack of related packages against each other[1].
You can do that in pbuilder (https://wiki.debian.org/PbuilderTricks ;
also allows testing locally-built packages in a pbuilder --login
session), but b
I vaguely recall that static linking is considered a bad idea in Debian,
for much the same reasons that embedded code copies are, but I can't
find this actually written down anywhere.
I'm working on packaging pocl (ITP #676504), which uses libllvm and
libclang. Dynamically linking libclang ma
> so basically it should provide only a -dev package. Is it ok to
> package only -dev, or is it agains policies?
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". T
Which version of git-buildpackage / pbuilder is this, and is the Lintian
call the default in your version (it isn't in mine) or something you
added? It worked for me in Ubuntu Saucy (git-buildpackage 0.6.3ubuntu1,
pbuilder 0.215ubuntu2, called with DIST=sid BUILDER=pbuilder
git-buildpackage --
Although we do have a unsolved
issue due to the ambiguity when there are more than one concrete
implementations in a package repository. This means we can't simply
install high-level application packages and have apt-get resolve all
their dependencies automatically, as the packages for the specif
It looks as MBF, but I would like someone more experienced to give advice.
The transitions policy is here:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
We do not have automation
to rebuild packages and file FTBFS bugs, do we?
Automated whole-archive rebuilds have been done (see e.g.
Without Javascript the web becomes a much more unexcited place.
Regrettably Iceweasel seems not to offer finely granulated enabling.
A whitelist would be nice.
That's available in xul-ext-noscript
Your upstream appear to be aware of this problem, but given that the
packaged version is from after then, their first attempt evidently
wasn't a full fix:
https://github.com/torch/torch7/pull/755
https://sources.debian.net/src/lua-torch-torch7/0~20161002-geb397ad-1/lib/TH/generic/simd/simd.h/
(
The purpose of a -dbg package is to provide a mapping between binary
addresses and source line numbers/variable names, not to provide the
source itself: it's working if your debug backtraces are of the form
#3 0x00ed4188 in SGPropertyNode::set_string (this=0x7eaa480,
val=0x20d79a0
Maybe this is beyond dpkg's job and apt or aptitude would handle that just fine.
I suspect that's the issue: I don't think dpkg knows how to find
packages you didn't explicitly give it (sources.list is in /etc/apt, not
/etc/dpkg...), so if dependencies require other packages it will error
out
Ubuntu has some of its security flags enabled by default in the compiler
itself, so explicit hardening CFLAGS are unnecessary (but harmless):
https://wiki.ubuntu.com/Security/Features
To check that this has worked, you can use
https://wiki.debian.org/Hardening#Validation
However, that's the
New upstream versions uploaded now generally won't get into Jessie, as
the now-required 10-day delay is longer than the time remaining before
freeze.
As the preferred way to do bug fixes during the freeze is to upload them
to unstable, having a new upstream version sitting in unstable during a
Hmm, perhaps I misinterpret [1], but it says "on the 5th of November
2014, and we will run one automated migration at that time".
...under the existing automated migration rules, including the 10-day
rule (so anything uploaded now won't qualify). "Unlike the Wheezy
freeze, we are not planning t
The + scheme is obsolete. If anything, it should be "-3+deb8u1".
Documentation: last paragraph of Developer's Reference §5.11.2.
5.13.3 (t-p-u) still has the old scheme: is that a bug in
developers-reference?
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subjec
If the several hours are spent compiling with gcc (likely), another
option is ccache; this is a little slower, but works across pbuilder
sessions (though deliberately not gcc upgrades, common in sid),
and is less likely to break things by reusing files it shouldn't
(as it requires the compiler opt
x86intrin.h is x86-only because it exists specifically to provide direct
access to x86 instructions. If the software in question has a plain-C
fallback, enable it; if not, keeping it x86-only is likely to be the
only reasonable solution.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lis
The valid way to specify "libcfitsio-dev (>= 3.310) or libcfitsio3-dev
(>= 3.310, << 3.370)" would be to use A|(B&C) = (A|B)&(A|C):
libcfitsio-dev (>= 3.310) | libcfitsio3-dev (>= 3.310), libcfitsio-dev
(>= 3.310) | libcfitsio3-dev (<< 3.370)
but you probably don't actually need that: as libc
.install uses shell wildcards, not regexes, so /usr/lib/*/subdirectory
The standard name on amd64 is actually x86_64-linux-gnu
(https://wiki.debian.org/Multiarch/Tuples).
I sent this (without the line wrap, and twice in case it got lost);
nothing happened to the bug, and I didn't get an acknowledgement or
error message back. What am I doing wrong?
Forwarded Message
Date: Sat, 2 Sep 2017 15:17:55 +0100
From: Rebecca N. Palmer
To: Debia
I received the below warning, but am not knowingly bouncing anything.
What might cause this?
- Have I set something up wrong?
I use Thunderbird, and have the junk settings set to mark junk as such
but not move it anywhere (as this is a fairly new install: when it has
adequately learned what I
I suspect this is caused by bumping debhelper compat (while often a good
idea, this is intentionally *not* risk-free, which is why it requires
explicit action), but I haven't actually tried fixing it by reverting this.
codesearch finds that message in dwz:
https://sources.debian.org/src/dwz/0.1
Given that the error is "Illegal instruction", and reproducibly happens
on x86-bm-01 and not the other machines we've tried, could it be
something assuming CPU features more recent than the amd64 baseline?
If so, it's not obvious where: scilab does contain some C/C++ code (as
well as Java), bu
Control: found -1 6.0.1-10
(I suggest opening a new bug for the 6.0.2 issues: as noted above, that
probably won't be accepted for buster even if we do get it to build.)
Running what I think is the relevant step in a debugger:
* Go to the top level directory of a _built_ source tree (i.e. one t
gbp import-orig --uscan --pristine-tar is the same command as I normally
use.
Did it fail with something different the first time? If so, it might
have failed after creating the 4.0.3 tag, leaving it in the way of
future attempts.
What git repository are you running it in? It should be run
On 07/07/2019 03:03, pkgoyq@neverbox.com wrote:
On Sat, Jul 6, 2019 at 6:18 PM Rebecca N. Palmer wrote:
What git repository are you running it in? It should be run in the
packaging repository, not the upstream one.
From the next post, it was being run in the right place.
(The
(a) The git-buildpackage manual [0] mentions, and [1] further discusses,
a workflow that imports *both* upstream's git and upstream's tarball of
the same release:
upstream-vcsuUuuUu
\ \
upstream-for-gbp --i--
Andrey Rahmatullin wrote:
If a remote has a branch this doesn't mean your repo has the same branch.
Is this intended as agreement with my "rename upstream/master with git
branch -u" proposal? Or is it a suggestion to delete Salsa/master and
force-push upstream/master over it (i.e. rewrite hi
Soft ping... Would you be willing to provide some guidance
Two people already did:
https://lists.debian.org/debian-mentors/2019/08/msg00098.html
https://lists.debian.org/debian-mentors/2019/08/msg00099.html
(Note that it is Debian list policy [0] to send replies to the list
only, not the se
Are you running out of memory?
The linking step of a build can use large amounts of memory (>100x more
than the final binary size). Running out of RAM often causes a
(near-)hang not a crash, even without swap.
To check, try running the compile with a system monitor (e.g.
gnome-system-monito
https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages
git-pbuilder builds in a chroot, containing build-essential and the
build dependencies. (One reason for doing this is to have _only_ those
packages available, and not anything else you happen to have installed,
as a check that the declared build dependencies do include everything
needed.)
H
Control: reassign -1 python3-sphinx-astropy
Control: tags -1 patch
(untested)
(If reading this in the bug, see
https://lists.debian.org/debian-mentors/2020/01/msg00295.html.)
An intersphinx_mapping can specify multiple alternatives for where to
find the inventory referred to, and these can be
Matthew Fernandez wrote (ordering changed):
I don’t get the same warning for mipsel and armel because the binary built fine
there. It’s just that the test suite didn’t complete.
No: by default, failed build-time tests fail the build (to make sure
they get noticed).
The "missing build on $ar
ccache: error: Failed to create directory
/sbuild-nonexistent/.ccache/tmp: Permission denied
You are using a build tool which expects a writable home directory,
which does not necessarily exist in build chroots.
Setting debhelper compat to 13 may help:
https://sources.debian.org/src/debhelper
Policy 12.7 [0] says that upstream release notes (as opposed to
changelogs) should be included in packages, and if the upstream format
is HTML, as both that format and gzipped plain text.
pandas has what upstream calls release notes but I'd call partway
between release notes and changelog, in
There's also Mono, which is already in Debian but has some limitations
(e.g. C# features newer than version 6 may not be available).
https://lists.debian.org/debian-cli/ has been mostly-inactive for years.
General information on packaging:
(Sorry, these may be out of date and/or not very clear -
https://wiki.debian.org/DebianAcademy are working on better ones.
Non-trust warning: wiki.debian.org is an anyone-can-edit site.)
https://wiki.debian.org/UpstreamGuide
https://wiki.debian.org/Packaging/
(These are general hints, I haven't looked at your particular package.)
Since the binary you want is arch-specific (_amd64 rather than _all),
use dpkg-buildpackage --build=source,any.
If the tests are long, you can skip them with DEB_BUILD_OPTIONS=nocheck.
If you're trying to fix a test fail
The default (I'm not sure if this is a global or per-team default) Salsa
CI pipeline tries to build and test packages on every commit.
For pandas, this always hits the 1 hour timeout, and hence "fails"
uselessly (wasting both the server's resources, and my attention when a
failure alert appear
The issue turned out to be that the pandas repository's settings were
pointed to a CI settings file outside the repository, so it wasn't even
looking at my debian/salsa-ci.yml.
As suggested by Eriberto's link, this setting is found at (starting from
the repository's page in Salsa, logged in) S
Report a bug (or if someone has already reported this against your
package, reassign it) with
Package: src:linux
Control: affects -1
'affects' means it will appear in your package's bug list but be marked
as linux's bug. (Example, now fixed:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug
Does that qualify for 'affects' ?
https://www.debian.org/Bugs/server-control#affects
Rebecca N. Palmer wrote:
> Package: src:linux
i wrote:
There seems to be no such package name.
Well, there is one. Only the package search engine does
not show it:
https://packages.debi
In a mail to 799...@bugs.debian.org:
Control: user debian-...@lists.debian.org
Control: usertags -1 + port-x32
Control: tags -1 + patch upstream
nnn@ does not accept usertags (in either Control: usertag or Usertags:
form - https://bugs.debian.org/798122 ).
In a mail to cont...@bugs.debian.org
Have you tried creating a new chroot that uses experimental? This at
least used to work, and given that package downgrades are not supported,
keeping separate chroots may be a better idea in the long run than
switching one back and forth.
https://wiki.debian.org/PbuilderTricks#How_to_build_for
src/ThirdParty and src/Library/RuleParser/quex contain embedded code
copies. Please ask upstream to remove them from their VCS and tarballs
and depend on them instead. You can then package them separately.
Alternatively, package them separately and remove all of them at
`debian/rules build` time b
46 matches
Mail list logo
