Re: Ccache size for pbuilder
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.debian.org
Archive: https://lists.debian.org/530cda80.4010...@bham.ac.uk
Re: Is there a way to preserve pbuilder chroot environment?
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 be aware that this method leaves the locally-built packages available until explicitly removed, so if you decide not to upload the new version of the library, don't forget to remove it before building anything that uses it. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53119ef7.4010...@bham.ac.uk
Static linking policy? (libllvm/libclang)
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 makes the package non-functional; dynamically linking libllvm works, but upstream don't recommend it due to https://github.com/pocl/pocl/issues/46 . Are those sufficient reasons to link statically, and if so, do I need to register having done so somewhere (i.e. "if you update libclang/libllvm, please binNMU pocl")? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535aa3f5.6020...@bham.ac.uk
Re: Library packaging and missing .a file
> 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". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535a9dab.8070...@bham.ac.uk
Re: git-pbuilder / pdebuild problem
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 --git-pbuilder), but I've never tried to build freeplane. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535c1fbc.4060...@bham.ac.uk
Re: Seeking recommendations wrt. target-specific packages
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 specific target may not be selected. A similar situation exists for hardware-specific packages already in Debian, such as xserver-xorg-video-*, xserver-xorg-input-*, printer-driver-*. We're considering adopting this for the OpenCL packages (*-opencl-icd). xorg's solution is to have an ORed dependency on (metapackage depending on all the hardware-specific packages) | (virtual package provided by each hardware-specific package): https://packages.debian.org/jessie/xserver-xorg The printer drivers have a similar metapackage, but with Recommends rather than Depends and no virtual package: https://packages.debian.org/sid/foomatic-db These default to installing all the hardware-specific packages (and hence require there to be a mechanism for choosing the right one to use), but allows users to choose one if they want to (if they're short of space/bandwidth, or want to use one that isn't in Debian main and hence isn't included in the metapackage).
Re: libgdbm transition
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. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768691 ), but I don't know whether they are done regularly.
Javascript Re: Multiarch hinter on package tracker: Shall i obey ?
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
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
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/ (Also in that file, it looks like they support arm* but try to detect it with __NEON__ , which doesn't work on our buildds...)
Re: Debug packages
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 "Shaders/cloud-shadowfunc.frag") at /home/palmer/fs_dev/git/simgear/simgear/props/props.cxx:511 (note the file name and line number) rather than #2 0x75aef83d in g_input_stream_read () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #3 0x7669c3e5 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 The source itself is in the source package, which can be installed with "apt-get source $package" if you have a deb-src line in /etc/apt/sources.list. This installs it in the current directory owned by the current user (i.e. conveniently editable), while apt-get install'd files are normally owned and editable only by root. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/537b0dec.4000...@bham.ac.uk
Re: Renaming a package and its corresponding debug package
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 rather than installing them. (To test locally with apt, you can use apt-ftparchive (https://wiki.debian.org/PbuilderTricks) or mini-dinstall (https://wiki.ubuntu.com/PbuilderHowto#Building_With_Local_Packages).) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5388b851.4000...@bham.ac.uk
Re: dh: default cmake options overridden
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 case in both 12.04 and 14.04, and dpkg-buildflags still includes them: trusty$ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 GCJFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53995be7.3000...@bham.ac.uk
Now may not be a good time for new upstream releases of existing packages
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 freeze can prevent you from fixing bugs in the old version in testing, and hence may not be a good idea: https://release.debian.org/jessie/freeze_policy.html You can avoid this by using experimental for new upstream versions at this time. (Entirely new packages, ie not previously in Debian at all, are OK: they won't get into Jessie either, but they won't be in the way by being in unstable.) Please don't be offended or put off: you're not the only ones who didn't notice, and it's not forbidden, just not something you want to do without being aware of the consequences. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e41e8.7060...@zoho.com
Bug#738101: RFS: awstats/7.3+dfsg-1
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 to give "carte blanche" unblocks to packages in unstable. So ensure your package is in testing before that last run." -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e5cf6.6020...@zoho.com
Re: Versioning for cherry picked after-freeze RC fixing packages
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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545c7c60.8050...@zoho.com
Re: Keep built files between pdebuild
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 options to match as well as the source).
Add this line to /etc/pbuilderrc
EXTRAPACKAGES="${EXTRAPACKAGES} ccache"
then run
sudo pbuilder --update --override-config
on your existing chroot(s).
If your package has a large tree of build-dependencies, you may want
to use eatmydata as well, to speed up the installation phase:
EXTRAPACKAGES="${EXTRAPACKAGES} ccache eatmydata"
export LD_PRELOAD=${LD_PRELOAD:+$LD_PRELOAD:}/usr/lib/`dpkg-architecture
-a${ARCH} -qDEB_HOST_MULTIARCH`/libeatmydata.so
#this will complain about the lack of eatmydata outside the chroot, but this
appears to be harmless
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d38d48.3070...@zoho.com
Re: Please help on build issue on arm64 (and others) (Was: failed arm64 build of vsearch 1.0.16+dfsg-1)
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...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e635ca.3010...@zoho.com
Re: build dependency range
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 libcfitsio3-dev >= 3.370 is an empty package depending on libcfitsio-dev, libcfitsio-dev (>= 3.310) | libcfitsio3-dev (>= 3.310) should be sufficient. Note that libcfitsio-dev needs to be first as buildds only look at the first alternative. I do not know if this rule also applies to backports, but given that jessie has 3.370 and wheezy 3.300, it won't be an issue for Debian backports anyway. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553b88e2.2050...@zoho.com
Re: How to deal with arch-specific paths in .install files
.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).
no response from cont...@bugs.debian.org
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: Debian Bug Tracking System #we use 3.9 on release architectures block 87 by 873403 unblock 873331 by 873403 #this version FTBFS with llvm 4.0, upstream git doesn't tags 873403 + upstream fixed-upstream forwarded 873403 https://lists.freedesktop.org/archives/beignet/2017-September/009153.html
"Excessive bounces" when I'm not intentionally bouncing
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 consider junk, I intend to tell it to move junk to my junk folder). The spam filtering option in my email provider's web interface is set to off. I keep very little on my provider's servers (so unlikely to be a lack-of-space issue), and am not aware of my provider having any recent technical problems. - Is a spammer creating what look like bounces but are actually new spam? Not sure if they would want to do this, or if they could do so well enough to fool a Debian listbot. - Is my email provider bouncing spam even with filtering "off"? Their documentation contains references to 'bouncing' spam [0], but is ambiguous as to whether this means a during-SMTP-transaction reject (OK?) or a later "returning to [apparent] sender" bounce (n!) [1]. (That particular documentation appears to be for business customers, as the settings page I have is the one documented at [2] which doesn't mention bouncing.) --- If they are, what is a good way to ask them to stop? Pointing them to https://wiki.debian.org/Teams/ListMaster/FAQ is an obvious option, but are there better ones? In particular, is there a risk that identifying the list operator as Debian, and hence potentially drawing their attention to the fact that Debian lists don't use what the wider world considers normal anti-spam measures (rejecting non-subscriber posts, and address hiding in public archives), might make the situation *worse*? --- If they won't stop this, are there methods other than email to comply with "must subscribe" rules? I already use the web interface for most of my Debian list reading, but I have a backport so I have to be subscribed to debian-backports [3]. [0] https://www.zoho.com/mail/help/guidelines-spam-control.html [1] https://www.zoho.com/mail/help/adminconsole/organization-spam-control.html [2] https://www.zoho.com/mail/help/anti-spam.html [3] https://backports.debian.org/Contribute/ A bot wrote: Your membership in the mailing list Pkg-opencl-devel has been disabled due to excessive bounces The last bounce received from you was dated 21-Nov-2018. You will not get any more messages from this list until you re-enable your membership. You will receive 3 more reminders like this before your membership in the list is deleted.
Re: dwz: libsleef3.debug: .debug_line reference above end of section
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.12-3/dwz.c/?hl=1016#L1016 dwz was added to the standard dh sequence in compat 12: https://sources.debian.org/src/debhelper/12/debhelper.pod/#L860 As it seems to relate to debug information, it might be a good idea to test whether that works: # apt-get install libsleef3-dbgsym $ gdb --args (gdb) break (gdb) run [wait for "hit Breakpoint", or if it's a program that spends most of its time in sleef, press Ctrl+C] (gdb) bt full [should show source line numbers and parameter values, i.e. like #909379 not #914021]
Re: scilab: FTBFS on all - baseline violation?
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), but there aren't any asm() or __builtin_ia32* calls in it, or any -march options in the build log. Maybe it's in a dependency, not scilab itself? There is an open "illegal instruction crash in Xcos" bug upstream, which may or may not be related: https://bugzilla.scilab.org/show_bug.cgi?id=11003#c6 Alexis Murzeau wrote: will such bug-fix upstream release be accepted in buster, now that we are in full freeze ? Generally not: Debian prefers not to fix minor bugs during freeze because this might accidentally create major ones. https://release.debian.org/buster/freeze_policy.html
Re: scilab: FTBFS on all
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 that
has had dpkg-buildpackage run on it; the same such tree can be used more
than once)
* Open the script file scilab-bin, and at line 117 (in function
func_exec_program_core), replace
-exec "$progdir/$program" ${1+"$@"}
+exec gdb --args "$progdir/$program" ${1+"$@"}
(or whatever debugging tool you want to use).
* Run:
LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1
_JAVA_OPTIONS='-Djava.awt.headless=true' ./bin/scilab-adv-cli
-noatomsautoload -nb -l en_US -nouserstartup -e "try
xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);"
Results:
* no debugging tool: succeeds (for me), with the usual nonfatal
IllegalStateException.
* qemu-x86_64-static -cpu Opteron_G3 (probably what x86-bm-01 has [0],
but note that qemu *doesn't* reject instructions that the CPU model
emulated doesn't have [1]): hangs using a full core of CPU.
* gdb: crashes with segfault and corrupt-stack backtrace,
Thread 1 "scilab-bin" received signal SIGSEGV, Segmentation fault.
0x7fffc096851b in ?? ()
(gdb) bt full
#0 0x7fffc096851b in ?? ()
No symbol table info available.
#1 0x0206 in ?? ()
No symbol table info available.
#2 0x7fffc0968280 in ?? ()
No symbol table info available.
#3 0x776c5034 in Abstract_VM_Version::_vm_major_version ()
from /usr/lib/jvm/default-java/lib/server/libjvm.so
No symbol table info available.
#4 0x7fffbe10 in ?? ()
No symbol table info available.
#5 0x773317ca in VM_Version::get_processor_features ()
at ./src/hotspot/cpu/x86/vm_version_x86.cpp:565
use_avx_limit =
buf =
"P\372]UUU\000\000\000\000\000\000\000\000\000\000\004\f\000\000\000\000\000\000\320\335\062\367\377\177\000\000\001\000\000\000\004",
'\000' , "\020", '\000' ,
"\310\235C\367\377\177\000\000\327\234C\367\377\177\000\000\001", '\000'
, "
vq\367\377\177\000\000\002\000\000\000\000\000\000\000S\000\000\000\032",
'\000' ,
"p\372]UUU\000\000p\372]UUU\000\000\000\000\000\000\000\000\000\000"...
use_sse_limit =
cache_line_size =
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
* valgrind: reports a _lot_ of invalid memory accesses, then crashes
with segfault
* (jvm doesn't work - .libs/scilab-bin is a native executable, not a
Java file)
This suggests that it is memory corruption after all: the "illegal
instruction" might be a corrupt stack returning to somewhere that was
never meant to be executable code.
[0] https://lists.debian.org/debian-wb-team/2019/05/msg4.html
[1] https://bugs.launchpad.net/qemu/+bug/1818075
Re: Importing a new upstream version
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 in the packaging repository, not the upstream one. (The package's Vcs-Git field currently points to upstream, which is itself a bug.)
Re: Importing a new upstream version
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 package's Vcs-Git field currently points to upstream, which is itself a bug.) Please elaborate what you mean, Rebecca, Did you mean that the following 2-line pointing to the wrong place? https://salsa.debian.org/debian/shc/blob/master/debian/control#L10-11 It was wrong last time the package was uploaded (which is what I found on tracker.debian.org), but has already been fixed in salsa: https://salsa.debian.org/debian/shc/commit/0a184cd3262e0b1bcdb0a1e8cdd5a909a4acfdef Sorry for the false alarm.
Packaging repository using both upstream-as-git and tarballs / branch name conflicts
(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--i--- \ \ debian -iP--ppPippP-- u, U = upstream commit, release p, P = packaging commit, release i = tarball+git import (gbp import-orig --upstream-vcs-tag) gbp --upstream-branch points to upstream-for-gbp upstream-vcs's remote points to upstream's repo This also allows git-only and tarball-only imports to coexist with the above and each other: upstream-vcsuUuuuUuuUu \ \ upstream-for-gbp --m---\--o--- \ \ \ debian -mP--mppP---oppP-- m = git only import (git merge or gbp import-ref) o = tarball only import (gbp import-orig) (Building the second form of git-only requires temporarily pointing --upstream-branch to upstream-for-gbp, so I suggest preferring the first one for the occasional unreleased-so-no-tarball snapshot in a normally tarball-using repository.) This option seems to be missing from the wiki page [2]: it only has git-only, tarball-only, and "salsa git from upstream git only, archive .orig from tarball" (noting the "they might not match" problem with the last). Is this omission a recommendation against it, or should it be added? --- (b) How do I deal with branch/tag name conflicts between upstream and packaging? There are at least two ways conflicts can happen by accident: (i) gbp defaults to naming the packaging branch 'master', which is also plain git's default name for the first branch of a new repository. (ii) gbp's upstream-branch/-tag settings are used both for reading (build) and writing (import-orig). Hence, if a contributor using upstream-as-git commits a debian/gbp.conf with these set to the upstream branch name and tag format, then another contributor imports an upstream tarball with gbp import-orig, the tarball-import commit ends up on what was the upstream-as-git branch with an upstream-format tag name [3]. Given that Git considers the same final contents via a different history to be a different commit number, I suspect (but haven't tried) that this makes that branch no longer usable for 'git pull' from upstream. [4] suggests that the command to pull a branch with a different name is git branch -u upstream/master upstream-vcs Is this correct, and will it sanely handle tag conflicts (e.g. by skipping the conflicting tags)? Is there a convention for what name to give this branch? Is there a standard way to tell gbp "this is an upstream-as-git-only repository, don't import tarballs" to prevent (ii) in future? (Avoiding (i) for new repositories is DEP-14 / #829444.) [0] https://sources.debian.org/src/git-buildpackage/0.9.14/docs/chapters/import.xml/#L233, or if you have it installed, file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664771 [2] https://wiki.debian.org/GitPackagingSurvey [3] I have seen what appears to be a real example of this on Salsa. [4] https://github.com/Debian/pkg-go-tools/blob/master/cmd/pgt-remote-add-upstream/upstream.go
Re: Packaging repository using both upstream-as-git and tarballs / branch name conflicts
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 history to "this mistake never happened", with the implied breakage of other existing clones [0])? Then don't do that. A repo either uses upstream tags directly or uses upstream/* tags that cannot clash with the upstream ones. Should gbp import-orig refuse to do anything (with an error stating that tarballs should not be imported into a git-only repository) if upstream-tag doesn't start with upstream/ ? I tried to ask codesearch how many packages currently set a non-upstream/* upstream-tag in gbp.conf, but it didn't find even the one I know about. [0] https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase
Re: Fwd: NATS Server Debian Package
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 sender: non-subscribers who want a reply are expected to check an archive service such as [1]. Unfortunately, that policy means you might not see this either, since appearing to not see earlier replies is not an _explicit_ request to be Ccd.) [0] https://www.debian.org/MailingLists/#codeofconduct [1] https://lists.debian.org/completeindex.html
Re: System freeze while compiling
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-monitor) open.
Re: Debian account creation
https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages
Re: Build dependencies not being installed when building postfix for stretch
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.)
However, before entering the chroot, it tries to run debian/rules clean
*outside* the chroot; in some cases the clean step needs some of the
build dependencies, so this can fail.
I'm not sure if this should be considered a bug, but this is what I use
to turn it off:
--- a/usr/bin/pdebuild
+++ b/usr/bin/pdebuild
@@ -85,9 +85,9 @@ else
# eval is needed to reverse that.
SOURCE_OPTIONS=$(get_source_options)
eval dpkg-source ${SOURCE_OPTIONS} --before-build .
-if should_clean_source; then
-"${BUILDSOURCEROOTCMD}" debian/rules clean
-fi
+#if should_clean_source; then
+#"${BUILDSOURCEROOTCMD}" debian/rules clean
+#fi
eval dpkg-source ${SOURCE_OPTIONS} -b .
if ! [ "../${DSC}" -ef "${BUILDRESULT}/${DSC}" ]; then
log.i "Generating source changes file for original dsc"
Re: local intersphinx
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 a mix of URLs and local
files:
https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#confval-intersphinx_mapping
Hence, to prefer the local inventory if it is installed, but still allow
downloading for non-buildd users:
intersphinx_mapping = {
'python': ('https://docs.python.org/3/',
- (None, 'http://data.astropy.org/intersphinx/python3.inv')),
+ ('/usr/share/doc/python3-doc/html/objects.inv', None,
'http://data.astropy.org/intersphinx/python3.inv')),
[...similar for the others...]
These local inventory files are in the -doc packages, so
(build-)dependencies on these are also required.
Re: blocked migrations due to timeout
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 $arch" warning only appears if the package is currently in testing on $arch. (Like most bugs, build failures only block testing migration if they are *regressions*.) Hence, in this case it appears for arm64 and mipsel but not armel. The "arch:$arch not built yet, autopkgtest delayed there" warning only appears if $arch runs autopkgtests: currently this means amd64, arm64 and possibly (seems to be well behind) ppc64el. Yes, ctest swallows the normal stdout of the test script. For local dev and in CI I typically avoid this by running the test script directly, but I wanted as little magic in my debian/rules as possible so I let it do whatever its CMake defaults were. This should probably be changed (use override_dh_auto_test): Debian Policy requires builds to be as verbose as is reasonable [0], for the debugging reason you already noted. What is the general approach for long running test suites? Is there a way to extend the timeout? Or is it a hardline that test suites have to complete within the allotted time? The timeout is 300 minutes of *inactivity* (no output) [1]: a build(-time test) can take longer than this if it keeps producing output. Hence, displaying the test's output might also fix this. (Autopkgtests probably shouldn't be this long, but you're already using something shorter there.) the version that is in testing for other platforms (2020.02.17-1) is listed as “Installed” for armel on the [buildd] QA page This might be a bug in that page - consider reporting it (against "buildd.debian.org"?). The "Logs" page [2] might be a better place to check the build status of old versions. [0] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules [1] https://sources.debian.org/src/sbuild/0.79.1-1/lib/Sbuild/Build.pm/?hl=2538#L2471 [2] https://buildd.debian.org/status/logs.php?pkg=rumur
Re: help with sbuild error
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/13.1/debhelper.pod/#L1088
12.7 "include release notes as text" when they are large
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 multiple files (one per upstream release), e.g. [1] They are currently included in the -doc package, in HTML format as /usr/share/doc/python-pandas-doc/html/whatsnew/*.html. Does it make sense to also concatenate them into a NEWS.gz when they are this large (it would be ~300K = ~5% of the package)? Does this belong in the -doc package like most library documentation (Policy 12.3) or is it an exception to that like the rest of 12.7? [0] https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes [1] https://pandas.pydata.org/docs/whatsnew/v1.0.0.html
Re: Packaging a .NET Core application & pbuilder
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.
Re: abydos
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/Intro https://www.debian.org/doc/manuals/maint-guide/ https://www.debian.org/devel/ Plugins and security: Thank you for thinking about this question. grep -rhi -e "Package:.*plugins" /var/lib/apt/lists/*_Packages finds many existing plugin collection packages, but they may have non-security reasons for being separate (e.g. package/dependencies size). An alternative way to reduce the exploitability of bugs in obscure formats would be to make the library's autodetect functionality default to only considering common formats (and/or to rejecting files with misleading filename extensions). Users who do want to use such a format would then have to request it at run time; this has the advantage (compared to installing a plugin package) of being one-off rather than default-permanent, but the disadvantage that it might be too easy to click yes without thinking.
Speeding up test builds Re: Building a few of packages
(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 failure bug, it is often possible to manually run a single test afterwards. (How depends on what test framework upstream are using.) If you still have the previous build tree, or expect to need more than one additional build, consider using dpkg-buildpackage --no-pre-clean to re-use the parts that haven't changed. (Warning: this may not have the same result as a normal build.) Tong Sun wrote: The only way I can think of is to change d/control file, comment out all other packages. This probably won't be much faster: it's likely to build everything and just not package up the pieces you didn't ask for. To do only part of the actual build, you probably need to modify debian/rules and/or the upstream build system. But that will cause trouble to dpkg-buildpackage Changes under debian/ shouldn't. Changes to upstream files do need to be made into an actual patch (dpkg-source --commit), but this is not the same as committing to git. or gbp buildpackage, which requires me checking in those temporary changes before starting This gbp check can be turned off with --git-ignore-new.
How to turn off Salsa CI for a package?
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 appears). https://salsa.debian.org/science-team/pandas/-/pipelines I've tried these attempts at "do nothing" in debian/salsa-ci.yml. Neither of them does that: the default CI still runs. https://salsa.debian.org/science-team/pandas/-/commits/debian workflow: rules: - when: never --- or (based on forensics-samples) --- --- default: script: - echo "disabled as it times out" We could instead increase the timeout, but I don't know if that much resource use would be appropriate.
Solved Re: How to turn off Salsa CI for a package?
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) Settings (in left menubar) > CI/CD > General pipelines > Expand > CI/CD configuration file. After pointing that setting back at debian/salsa-ci.yml, it does take the absence of such a file as "do nothing". The timeout length setting is on the same page.
Re: What to do with a kernel bug which lets my package work result look bad ?
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=767148 )
Re: What to do with a kernel bug which lets my package work result look bad ?
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.debian.org/search?keywords=linux&searchon=names&suite=stable§ion=all That search page defaults to searching binary packages, not source packages, and only the source package is named just "linux"; the binary packages are "linux-image-4.1.0-2-amd64", etc. "linux-source" is a binary package that actually contains source; it exists because a few packages (e.g. user-mode-linux, cpqarrayd) (build-)depend on it, as it is not possible to (build-)depend on source packages.
Re: Help getting a bug report in order
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: user debian-...@lists.debian.org usertags 799556 + port-x32 tags 799556 + patch upstream It's 'usertag' at control@ (but Usertags: on a new bug to submit@).
Re: cowbuilder/pbuilder: require newer version from experimental
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_different_distributions There are tools to help manage multiple chroots in ubuntu-dev-tools, though I don't use them myself: https://wiki.ubuntu.com/PbuilderHowto#Using_pbuilder-dist_to_manage_different_architectures_and_distro_releases
Bug#825302: RFS: usbguard/0.4-2 [ITP]
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 before dh_auto_configure and at `debian/rules clean` time (or just have uscan auto-repack the upstream tarball using Files-Excluded). They're there to allow building usbguard on systems without those libraries packaged: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-on-Ubuntu-14-04 Upstream already agree they shouldn't be used if system packages are available: see https://apps.fedoraproject.org/packages/usbguard/sources/spec lines 55-65 This line in the README.md indicates a possible flaw in usbguard; can it block new USB keyboards if there is a built-in keyboard or one keyboard plugged in via a non-USB method such as PS/2? This is just an example; you can block USB keyboards entirely (but check lsusb first, as some physically built-in devices are internally USB), but probably can't automatically check whether there's a non-USB keyboard. You can also allow only those devices currently connected (usbguard generate-policy).
