Re: dh_install by file suffix

Hi Niels, On 16.07.23 09:32, Niels Thykier wrote: The "iraf" source package needs to divide these files into user related files (for the "iraf" and "iraf-noao" packages) and development related files (for "iraf-dev" and "iraf-noao-dev"). The problem is now, that the division is (mainly) by

Re: dh_install by file suffix

d need ~40,000). Any better idea? Best Ole On 15.07.23 21:01, Ole Streicher wrote: Hi, I am upgrading one of my packages (iraf) to a new version. The new version comes with a "make install", which installs everything under /usr/lib/iraf/ (and some other places). The "iraf&

dh_install by file suffix

Hi, I am upgrading one of my packages (iraf) to a new version. The new version comes with a "make install", which installs everything under /usr/lib/iraf/ (and some other places). The "iraf" source package needs to divide these files into user related files (for the "iraf" and "iraf-noao"

Re: lintian errors packaging Barry's Emacs

Hi Santiago, Santiago Vila writes: > If you don't have deb-src lines, they are the same as the usual deb lines > except that they begin with deb-src. Just curious: why are the deb line not used by default here? Best Ole

Re: lintian errors packaging Barry's Emacs

Hi Barry, Barry Scott writes: > I am build my first Debian package for Barry's Emacs > (https:://barrys-emacs.org) Aside from Santiagos technical tips: If you really want to contribute your package to the Debian distribution, you should also have a few other things in mind: * Your package

Problem with LD_PRELOAD in cowbuilder

Hi, My cowbuilder setup has been working properly for many years, however now I have a strange problem with the cowbuilder in one (new) cmake project: When building this project, there appear many lines ERROR: ld.so: object '.' from LD_PRELOAD cannot be preloaded (cannot read file data):

Re: Environment variable for package base dir

Gianfranco Costamagna writes: > $CURDIR? Yes, is what I also finally found to be working. Cheers Ole

Environment variable for package base dir

Hi, one of my packages https://salsa.debian.org/debian-astro-team/sep requires to specify a path relative to the package base dir (the path to a shared library), which is important for build and for testing. I, Python, it is specified in setup.py. I solved this the following way: d/rules:

Re: combining pybuild and cmake

Hi Jeremy, Jeremy Sowden writes: > Don't know whether it the proper way to do it, but this: > > $ cat debian/rules > #!/usr/bin/make -f > #export DH_VERBOSE=1 > > %: > dh $@ --with python3 > > override_dh_auto_clean: > dh_auto_clean -O--buildsystem=cmake >

combining pybuild and cmake

Hi, I am working on a package (https://salsa.debian.org/debian-astro-team/sep), that needs a two-stage build: First, a library is built with cmake/make, and then a Python (wrapper) package is built the usual way. I tried to just have two commands in d/rules:

Re: Package upload failed only due GPG expiration?

Hi Filip, otherwise, I would just sponsor you upload(s) in the meantime. Justping me if needed. Cheers Ole Filip Hroch writes: > Hi Sebastian, and Andrey, > > thank you very much for that help. I decided to practise my patience, > there's no hurry for Fitspng upload. > > > Sebastian Ramacher

Re: Do autopkgtest for non-listed architectures prevent migration?

Hi Helge, Helge Deller writes: > That's why I'm saying that you shouldn't exclude by default a *specific* > architecture. The problem is often not bound to that architecture, but by > the specifics which define that architecture (endianess, 32/64-bit, ...). this brings me to the point why we

Re: Do autopkgtest for non-listed architectures prevent migration?

Helge Deller writes: > On 1/24/22 09:10, Ole Streicher wrote: >> Wookey writes: >>> If the package builds on the 32bit arches then I would advise that you >>> let it build. We always try to build for all arches in debian and it >>> is very annoying if you hav

Re: Do autopkgtest for non-listed architectures prevent migration?

Wookey writes: > If the package builds on the 32bit arches then I would advise that you > let it build. We always try to build for all arches in debian and it > is very annoying if you have say an armhf machine and something is not > available just because there was some test failure so upstream

Re: Uscan with gitlab and user provided tarball

Paul Wise writes: > On Tue, 2021-10-12 at 14:43 +0200, Ole Streicher wrote: > >> https://gitlab.com/aroffringa/wsclean >> >> He uses git submodules > > These all look like embedded code copies, so I suggest packaging them > separately instead of includin

Uscan with gitlab and user provided tarball

Hi, the upstream of one of my packages recently moved from sourceforge to Gitlab: https://gitlab.com/aroffringa/wsclean He uses git submodules, and this makes the automatically created tarball incomplete. For my convenience, he created (and hopefully will continue so) a manual asset, which is

Detect whether a debuild is running

Hi, we got a bug report about network access during build (#949464) that was caused by sphinxdoc. The root of this is a list maintained in another package, python3-sphinx-astropy (sphinx_astropy/conf/v1.py): intersphinx_mapping = { 'python': ('https://docs.python.org/3/',

Re: Symbols files for C++ libraries

Andrey Rahmatullin writes: > On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote: >> for the "casacore" package (written in C++), we wanted to introduce >> symbols files for the shared libraries it produces. However, this >> somehow does n

Symbols files for C++ libraries

Hi, for the "casacore" package (written in C++), we wanted to introduce symbols files for the shared libraries it produces. However, this somehow does not work, as they seem to depend on the architecture and/or the C++ compiler version:

Package name change problems

Hi, I am in the process to rename one of my packages (source and binary packages), from "sextractor" to "source-extractor" (see #941466 for rationale). For this, I followed the Wiki; in d/control: Package: source-extractor Architecture: any Depends: ${misc:Depends}, ${shlibs:Depends} Breaks:

dwz failures

Hi, I have a larger package (eso-midas) that built successfully over the last years. However, a new binNMU failed last night on mips/mipsel/mips64 with the cryptic error message dh_dwz -a dh_dwz: dwz -q -mdebian/eso-midas/usr/lib/debug/.dwz/mipsel-linux-gnu/eso-midas.debug

Bug#919413: RFS: doxygen/1.8.15-1 [ITA]

Control: severity 921295 important Control: severity -1 normal (setting severity of RFS back to normal) https://release.debian.org/buster/freeze_policy.html > Transition Freeze > Starting 2019-01-12, new transitions and large/disruptive changes are no > longer acceptable for buster. I am

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

Hi Andreas, one thing I usually do in such cases is to rebuild the package adding "-fsanitize=address -O0" flags (optimization just to understand better what happens in the source). This switches the address sanitizer on . This can test

Re: Removing a package from unstable

Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 09:24:06PM +0100, Ole Streicher wrote: >> I have a source package (python-astropy) that I now want to remove from >> unstable. I took care that all reverse dependencies were removed now in >> recent uploads. As suggested i

Removing a package from unstable

Hi, I have a source package (python-astropy) that I now want to remove from unstable. I took care that all reverse dependencies were removed now in recent uploads. As suggested in [1], I first issued $ ssh mirror.ftp-master.debian.org "dak rm -Rn python-astropy" to see whether it would run

Arch:all package dependencies

Hi, I recently created a new binary package "iraf-wcstools", which is Arch:all, but depends on architecture dependent packages. Specifically, it depends on "iraf", which is available only on selected architectures (f.e. not on s390x): Package: iraf-wcstools Architecture: all Depends: iraf, [...]

Splitting source package into two

Hi, I am the maintainer of the "python-astropy" package, that currently creates packages for both Python 2 and Python 3. Both packages have a number of reverse dependencies. Recently, upstream announced a new version 3.0 of astropy, which supports Python 3 only, and I want to have a smooth

Re: Dependencies across architectures

Hi Paul, Paul Wise <p...@debian.org> writes: > On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote: >> "iraf" exists only on selected architectures due to some required >> assembler code for each arch and problems with big endian. > There could be a fallback in

Dependencies across architectures

Hi, I have an "arch: all" package "python3-pyraf" (source package: "pyraf"), that has a dependency on the package "iraf", but no build dependency on that. "iraf" exists only on selected architectures due to some required assembler code for each arch and problems with big endian. python3-pyraf is

How to switch all->any?

Hi, I have a (Python 3) package that introduced some system dependent binaries, and therefore the package had to switch from "all" to "any". The package is not in testing in the moment. However, it also does not migrate with the message "missing build on all: python3-sunpy (from 0.7.9-1)". How

Re: How to find Multi-Arch path(s)

Guillem Jover writes: > The point is that the Multi-Arch concept in Debian is all about the > interfaces. How packages and files interface with each other, and > what is possible and allowed. Some examples: > > * A script might be arch-independent in the contents sense;

Re: How to find Multi-Arch path(s)

Hi Guillem, thanks for the quick answer. Guillem Jover <guil...@debian.org> writes: > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote: >> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf > > It that was to be used, then it should be DEB_HOST_MULTIARCH, the > _TARGET_ v

How to find Multi-Arch path(s)

Hi, I want to package a software, "iraf" (with extensions) that uses some system dependent binaries internally. Some of the extensions will be available in 32 bit only, so this is a good use case for Multi-Arch. That means, that the binaries will go to /usr/lib/${DEB_TARGET_MULTIARCH}/iraf At

Re: ocaml not migrating?

Hi Andrey, Andrey Rahmatullin <w...@debian.org> writes: > On Thu, Oct 12, 2017 at 10:03:46AM +0200, Ole Streicher wrote: >> since a few days, ocaml has the "Migration status: OK: Will attempt >> migration", but it does not migrate. > https://release.debian.

ocaml not migrating?

Hi, since a few days, ocaml has the "Migration status: OK: Will attempt migration", but it does not migrate. https://tracker.debian.org/pkg/ocaml Since I have a few packages depending on ocaml (namely plplot and its reverse dependencies, gnudatalanguage) which are set to AUTORM, I am wondering

Piumparts problem

Hi, one of my packages is marked as "Rejected due to piuparts regression", but I don't understand the log message. https://piuparts.debian.org/sid/fail/postgresql-pgsphere_1.1.1+2017.08.30-1.log When I grep for "error:" there, the only thing I see here is: 0m13.8s ERROR: Command failed

Build-dependencies for qt5

Hi, I am adopting a package (plplot) that depends on (Qt4 or) Qt5. The description of the "qt5-default" package, says that this package should not be used to build a dependent package but to look into http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html instead. From this, I take that I

Re: Package not migrating

Hi Nils, Niels Thykier <ni...@thykier.net> writes: > Ole Streicher: >> Andrey Rahmatullin <w...@debian.org> writes: >>> On Thu, Aug 17, 2017 at 08:42:37PM +0200, Ole Streicher wrote: > The package is affected by the same issue that chocolate-doom was

Re: Package not migrating

Andrey Rahmatullin <w...@debian.org> writes: > On Thu, Aug 17, 2017 at 08:42:37PM +0200, Ole Streicher wrote: >> * Not touching package due to block request by adsb (check >> https://release.debian.org/testing/freeze_policy.html if update is >> needed) > http

Package not migrating

Hi, I have a package (cpl) that did not migrate since 38 days, but I don't see a reason: Excuse for cpl * Migration status: BLOCKED: Needs an approval (either due to a freeze or due to the source suite) * 38 days old (needed 10 days) * Not touching package due to block request by adsb (check

Re: Linitian orig-tarball-missing-upstream-signature

Hi Paul, Christian, Christian Seiler <christ...@iwakd.de> writes: > On 07/31/2017 10:54 AM, Paul Wise wrote: >> On Mon, Jul 31, 2017 at 4:24 AM, Ole Streicher wrote: >>> is not really helpful to me; at least I did not find a mention in the >>> Debian policy that

Linitian orig-tarball-missing-upstream-signature

Hi, since the last lintian update, I get an error orig-tarball-missing-upstream-signature for new packages which have the PGP signature check enabled (f.e. python-astropy, or python-astropy-helpers). The description | The packaging includes an upstream signing key but the corresponding | .asc

Re: How to make a shared lib recognized by debhelpers?

Gert Wollny <gw.foss...@gmail.com> writes: > Am Montag, den 17.07.2017, 21:20 +0200 schrieb Ole Streicher: > >> How can I do a proper handling of the library here? I guess (I am not >> an octave expert, however), that the name of the library shall not be >> chang

Re: How to make a shared lib recognized by debhelpers?

James Cowgill writes: > You have been hit by bug #35733 in debhelper. Possibly #862909 might > apply here as well. Whow! That is quite old. I am wondering why I can't just put the library into .shlibs (which is mentioned, but not documented in the dh_makeshlibs manpage) --

Re: How to make a shared lib recognized by debhelpers?

Andrey Rahmatullin writes: > What does file(1) return for this file? The expected: $ file plplot_octave.oct plplot_octave.oct: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=98a4031426db920f83eb6bd2ac63b52be705fee8, not stripped I

How to make a shared lib recognized by debhelpers?

Hi, I am currently adopting plplot [1], which included a simplification and modernization of the build system (using modern debhelpers). I now have the problem, that one of the shared libraries is probably not detected correctly: "lintian" tells me E: octave-plplot: unstripped-binary-or-object

Re: mpgrafic - mpirun test program as root in automatic build

Paul Wise <p...@debian.org> writes: > On Wed, Jan 18, 2017 at 3:58 PM, Ole Streicher wrote: > >> Also when using cowbuilder? At least I see the whole build done by root >> when running in my cowbuilder chroot. That was the point that lead to >> the trouble here...

Re: mpgrafic - mpirun test program as root in automatic build

Paul Wise writes: > On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote: > >> I guess by "both of these" you mean "most of the build steps (apart from >> the 'debian/rules install' step)"? > > What I wrote wasn't clear and wasn't strictly true, sorry! > > When manually building

Re: mpgrafic - mpirun test program as root in automatic build

James Cowgill <jcowg...@debian.org> writes: > On 16/01/17 23:58, Boud Roukema wrote: >> Since, in general, there is no reason for mpirun to run as root, >> the sid version of mpirun (from openmpi) apparently refuses to run as root. >> (I have not reproduced this behav

Re: Package not migrating

Andrey Rahmatullin <w...@debian.org> writes: > On Thu, Jan 12, 2017 at 10:33:58AM +0100, Ole Streicher wrote: >> Hi, >> >> I still do not completely understand all causes why a package does not >> migrate: >> >> sinpy is a valida candidate but doesn't

Package not migrating

Hi, I still do not completely understand all causes why a package does not migrate: sinpy is a valida candidate but doesn't migrate. None of the pages shows a reason: https://qa.debian.org/excuses.php?package=sunpy https://release.debian.org/britney/update_excuses.html#sunpy At the same time,

Re: debian/watch: FTP with version encoded (only) in directory

Hi Paul, Paul Wise writes: > With just the ftp site alone it can't work (see below), luckily for > you there is a github page: > > http://www.star.bristol.ac.uk/~mbt/stilts/#install > https://github.com/Starlink/starjava/releases > > So this monstrosity should work: > >

debian/watch: FTP with version encoded (only) in directory

Hi, I have the following sample download URL ftp://andromeda.star.bris.ac.uk/pub/star/stilts/v3.0-9/stilts_src.zip Corresponding Debian version number should be 3.0.9. I tried version=3 options="uversionmangle=s/\-/./,filenamemangle=s/\/$/.zip/" \

Non-understandable piuparts

Hi, I have a piuparts message that I don't understand: https://piuparts.debian.org/sid/fail/python-pyvo_0.4.1+dfsg-1.log it basically complains the python-requests could not be installed; however this package is available both in sid and testing (for more than 6 months without change), and

Package not migrating

Hi, I have a package (casacore-data-tai-utc), that doesn't migrate to testing, even if it is marked as "valid candidate": excuses: * 12 days old (needed 10 days) * casacore-data-tai-utc/i386 unsatisfiable Depends: python3-casacore * Valid candidate The second item comes from the fact, that

Re: Debian privacy policy

Paul Wise <p...@debian.org> writes: > On Thu, Nov 17, 2016 at 12:17 AM, Ole Streicher wrote: >> a reference that Debian prefers strong privacy > > AFAICT we don't have an official statement about this, but: > https://lists.debian.org/debian-policy/2008/02/msg00060.html [...

Re: Debian privacy policy

Sean Whitton <spwhit...@spwhitton.name> writes: > On Wed, Nov 16, 2016 at 05:17:32PM +0100, Ole Streicher wrote: >> for a discussion with upstream (removal of a default "anonymously >> logging home" feature), I would like to have a reference that Debian >&g

Debian privacy policy

Hi, for a discussion with upstream (removal of a default "anonymously logging home" feature), I would like to have a reference that Debian prefers strong privacy (no default logging, even not anonymously) over usefullness for upstream. The only point I could find is the "Our priorities are our

Re: ITP's not showing up on debian-devel?

Andrey Rahmatullin writes: > On Mon, Nov 07, 2016 at 11:28:55PM -0800, Walter Landry wrote: >> Hi Everyone, >> >> I recently posted two ITP's >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843325 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843570 >> >> The

Re: Data updates in debian packages

Paul Wise <p...@debian.org> writes: > On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote: >> The package in question (casacore) wants them in a specific format "CASA >> table" (which is uniformly used within that package), and dependent >> packages access t

Re: Data updates in debian packages

Christian Seiler <christ...@iwakd.de> writes: > On 10/31/2016 09:07 AM, Ole Streicher wrote: [leap seconds] >> We need it to put correct time on astronomical registrations, so it is >> most important to have them once they are effective. Having them in >> advance

Re: Data updates in debian packages

Russ Allbery writes: > The required timeliness depends a lot on what you're using leap seconds > for, and in particular if you need to know about them far in advance, or > if it's only necessary to have an updated table before the leap second > itself arrives. We need it to put

Re: Data updates in debian packages

On 30.10.2016 04:38, Paul Wise wrote: > On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote: >> The update script itself could even be distributed with the casacore >> package itself. And for simplicity I would make >> casacore-data-autoupdater a binary package withi

Re: Data updates in debian packages

On 30.10.2016 04:42, Paul Wise wrote: > On Sun, Oct 30, 2016 at 4:36 AM, Ole Streicher wrote: > >> The canonical source for leap seconds is the IERS. Our current plan was >> to take the leap second list from there and build our package from this >> (as it is done in th

Re: Data updates in debian packages

Ben Finney <bign...@debian.org> writes: > Ole Streicher <oleb...@debian.org> writes: >> How sure can one be that they will be installed in-time? > > This confuses me too. If the file is installed, you have the > leap-seconds data for the installed version of ‘t

Re: Data updates in debian packages

Hi Paul, On 29.10.2016 03:37, Paul Wise wrote: > On Fri, Oct 28, 2016 at 6:38 PM, Ole Streicher wrote: >> We have the problem (I am not sure whether I posted about this already), >> that the "casacore" package needs additional "casacore-data-XXX" >> p

Data updates in debian packages

Hi, We have the problem (I am not sure whether I posted about this already), that the "casacore" package needs additional "casacore-data-XXX" packages, providing the basic data to work with casacore. Some of the data are almost immutable, others (for example leap seconds) are changing every year

Re: dcut cancel|rm command

Hi, On 18.10.2016 18:17, Gianfranco Costamagna wrote: >> dcut cancel -f wsclean_1.12-3_source.changes >> >> but this returns a mail "No upload found: >> wsclean_1.12-3_source.changes". > > the package has already been accepted? It isn't; at least I didn't get the acceptance mail and it is not

dcut cancel|rm command

Hi, I am (again) stuck with using the dcut tool to remove an upload. I have two packages which are uploaded, but still not accepted (in the incoming queue), which I want to cancel: wsclean and aoflagger. I thought the way to do would be (with dcut-ng): dcut cancel -f

Re: Version comparison with "+repack"

Adam Borowski writes: > On Fri, Oct 07, 2016 at 11:23:45AM +, Mattia Rizzolo wrote: >> agreed. What about >> 7.5~rc.2+repack >> ? >> >> The full stop is ugly at my eyes, but does the work and there are worse >> things in the world. > > What about rc-2+repack? A

Re: Version comparison with "+repack"

Mattia Rizzolo <mat...@debian.org> writes: > On Fri, Oct 07, 2016 at 12:26:09PM +0200, Ole Streicher wrote: >> Santiago Vila <sanv...@unex.es> writes: >> > On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote: >> >> dpkg --compare-versions 7.5~rc

Re: Version comparison with "+repack"

Santiago Vila <sanv...@unex.es> writes: > On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote: >> dpkg --compare-versions 7.5~rc+repack lt 7.5~rc2+repack && echo lt || echo >> ge >> ge >> >> What is the best way to fix this? > > The

Version comparison with "+repack"

Hi, my package "saods9" has currently a RC release in experimental that is named 7.5~rc+repack-1 Now, upstream released a second RC which I want to upload as well: 7.5~rc2+repack-1 However, it turns out that this release is actually *smaller* than the first RC release? I originally thought

Re: NFS_SUPER_MAGIC portability

Christian Seiler writes: > Therefore, it might be a good idea to know _why_ you want to check for > NFS here? What's the use case? Perhaps there's a better and more > portable way to check for that specific thing. That was the key question ;-) Scanning the code showed me

NFS_SUPER_MAGIC portability

Hi, I have the problem that in a package (casacore) there is basically the following code: -8< #include #include Bool Directory::isNFSMounted() const { struct statfs buf; if (statfs

Re: uscan for a single text file

Sergio Durigan Junior <sergi...@sergiodj.net> writes: > On Sunday, July 17 2016, Ole Streicher wrote: >> If mk-origtargz doesn't repack it, why does it look into it? The symlink >> could be created without as well. > > It makes sure that there is a tarball com

Re: uscan for a single text file

Paul Wise <p...@debian.org> writes: > On Fri, Jul 15, 2016 at 11:13 PM, Ole Streicher wrote: > >> I want to create a watch file for a package that contains a single text >> file (which itself has the version into it): > ... >> The "repackage.sh&qu

Re: uscan for a single text file

Sergio Durigan Junior <sergi...@sergiodj.net> writes: > On Saturday, July 16 2016, Ole Streicher wrote: > >> Sergio Durigan Junior <sergi...@sergiodj.net> writes: >>>> What is wrong here? I thought that mk-orig.tar.gz should be called only >>>&g

Re: uscan for a single text file

Sergio Durigan Junior writes: >> What is wrong here? I thought that mk-orig.tar.gz should be called only >> when it is a tar archive? > > Yeah, uscan is the responsible for invoking mk-origtargz. That can be a > problem indeed for cases like yours. Hmm, the manpage of

uscan for a single text file

Hi, I want to create a watch file for a package that contains a single text file (which itself has the version into it): --8 version=3 http://www.ngdc.noaa.gov/IAGA/vmod/igrf.html igrf(\d+)coeffs.txt \ debian debian/repackage.sh

Weird unmet build dependencies on buildds

Hi, I am trying to get my package "dpuser" compiled. While this works nicely on my local pbuilder with up-to-date packages, it fails on the buildds: https://buildd.debian.org/status/package.php?p=dpuser f.e. for i386: ---8<- Dependency

Deterministic "ar" breaks build

Hi, since a while, the "ar" command is built with --enable-deterministic-archives, which basiacally resets (among others) the timestamp to null. This has the unfortune disadvantage, that Makefiles that use this timestamp do not work correctly anymore. For example, my wcslib package has

Re: Best practise for a drop-in replacement of a non-free package

Paul Wise <p...@debian.org> writes: > On Mon, May 23, 2016 at 12:11 AM, Ole Streicher wrote: > >> My question is more the first step , which includes giza as a library >> with the /potential/ to replace pgplot, but without a strong >> recommendation. > >

Re: Best practise for a drop-in replacement of a non-free package

Hi Paul, Paul Wise <p...@debian.org> writes: > On Sat, May 21, 2016 at 8:29 PM, Ole Streicher wrote: >> I intend to package the "giza" library [1] that is largely a replacement >> of the pgplot library that is in Debian non-free. > > Does that mean th

Best practise for a drop-in replacement of a non-free package

Hi all, I intend to package the "giza" library [1] that is largely a replacement of the pgplot library that is in Debian non-free. Pgplot is an all-in-one package that contains among others the following libraries and header file (no pkgconfig file here): /usr/include/cpgplot.h

Which libstdc++ library?

Hi, I have a package (dpuser [1]), that during execution may call the c++ compiler g++ for some on-the-fly-generated C++ files that use the standard C++ library. I am now curious on how I need to specify the runtime dependency from the -dev library? The C++ compiler is probably just the "g++"

Re: Package Naming

Hi Benda, Benda Xu writes: > I am packaging a library called "casacore" which provides > > libcasa_python3.so.2 and libcasa_python.so.2 > > with SONAME=2. > > How should them be named when the python major version and SONAME could > cause confusion? Since noone had a good

Re: Package Naming

Christian Kastner writes: > On 2016-05-11 03:41, Benda Xu wrote: >> I am packaging a library called "casacore" which provides >> libcasa_python3.so.2 and libcasa_python.so.2 >> with SONAME=2. >> How should them be named when the python major version and SONAME could >> cause

Re: Please help creating shared *and* static library with cmake

Andreas Tille writes: > I need to package libsdsl[1] as some precondition for a Debian Med > package. The default cmake build only creates a static library and I > found a patch to create a shared library. But since library packages > should include both I wonder how to get

Re: Bug#810822: ITP: MooseFS

Jakub Kruszona-Zawadzki writes: > On 15 Jan, 2016, at 15:09, Dmitry Smirnov wrote: >> For quite a while LizardFS is developed with community using public >> VCS and bug tracker (GitHub) as well as Gerrit code review system and >> continuous

Re: cowbuilder/pbuilder: require newer version from experimental

Alex Mestiashvili writes: >> What could be the cause that the dependency is not satisfied from >> experimental here? > may be a "cowbuilder --update" is missing ? No; I did this. I also tested that I can install it manually (with "apt-get

cowbuilder/pbuilder: require newer version from experimental

Hi, to build an "experimental" version of one of my packages, I need to specify a package that is in unstable (1.0.5-1) and in experimental (1.1~b1-1), and I need the experimental version here. With "cowbuilder --login --save-after-login", I have put the "experimental" distribution into

Re: Setting up CI environment

Tomasz Buchert <tom...@debian.org> writes: > On 21/10/15 10:34, Ole Streicher wrote: >> I was just trying to setup the debci environment, following the >> documentation > FTR, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799760 Thanks, that hint from the bug discus

Setting up CI environment

Hi, I was just trying to setup the debci environment, following the documentation https://ci.debian.net/doc/ However, when I run the command $ adt-run --user debci --output-dir /tmp/debci-output \ /var/cache/pbuilder/result/aplpy_1.0-1_amd64.changes \ --- schroot debci-unstable-amd64 I

Endianess testing?

Hi, how do I test the endianess of a system for the inclusion in debian/rules? lscpu | fgrep -q "Little Endian" comes in my mind; but is this safe? qemu-userland would probably report something wrong here? Best regards Ole

+dfsg extension with Files-Excluded: in d/copyright

Hi, when using the Files-Excluded: tag in debian/copyright, in the past there was an "+dfsg" suffix added to the version number automatically. This seems to have changed; is there a reason for that? Is there any case to use Files-Excluded: *without* actually adding the suffix? What is

Re: +dfsg extension with Files-Excluded: in d/copyright

Sebastiaan Couwenberg <sebas...@xs4all.nl> writes: > On 01-09-15 11:51, Ole Streicher wrote: >> What is recommended way for the watch file that it automatically >> generated to correct version number for a newly created orig.tar file? > Add the repacksuffix option Is

Re: Best practices for downloader packages

Adam Borowski kilob...@angband.pl writes: On Mon, Aug 17, 2015 at 01:29:12PM +0200, Ole Streicher wrote: * Since the download code if DFSG-Free, the downloader goes to contrib, independently of the copyright of the data, right? Right. which is a bit pity, since the package

Re: Best practices for downloader packages

Jakub Wilk jw...@debian.org writes: * Ole Streicher oleb...@debian.org, 2015-08-16, 19:17: * Shall it be native? There is no local upstream code, so the directory is just empty (except the debian/ subdir). However, native may not the best mark to it, since the package ist not really a debian

Best practices for downloader packages

Hi, I want to create a package that purely downloads some (large scientific) data, and I am unsure how to create the package: * Shall it be native? There is no local upstream code, so the directory is just empty (except the debian/ subdir). However, native may not the best mark to it, since

  1   2   3   >