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 ext
#x27;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 "ira
suffix? Otherwise, I would need to list the (~1000) files in the
"install" files, which is not very robust.
Cheers
Ole
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
fforts should be separated from the software
development itself and usually happens on the Salsa Gitlab server
[4]. I'd strongly recommend to allow team maintainance, to lower the
barrier of packaging-related contributions.
Best regards
Ole
[1] https://www.debian
ld happen. I already removed all eatmydata
mentions to make sure it is not the cause here. It seems that there is a
subtle difference between an unset LD_PRELOAD and an unset LD_PRELOAD,
and debhelper seem to make it empty instead of unsetting it.
Does anyone have an idea? This is not even my own package, but one the I
am mentoring - https://salsa.debian.org/debian-astro-team/elements
Best regards
Ole
Gianfranco Costamagna writes:
> $CURDIR?
Yes, is what I also finally found to be working.
Cheers
Ole
:
export BUILD_ROOT=$(shell pwd)
setup.py (patched):
buildroot = os.environ.get('BUILD_ROOT', '.')
This works nicely locally (cowbuilder) and in Salsa. However, on the
buildds, the build root is set empty and the build fails.
What is the normal way to get the package build root?
Best
Ole
dh_auto_clean -O--buildsystem=cmake
> dh_auto_clean -O--buildsystem=pybuild
[...]
> appears to put the right files in debian/tmp [...]
That solves my problem. Thank you very much!
Cheers
Ole
how re-executes the cmake build in the second step, doesn't call
setup.py at all, and then doesn't find files to put into the package.
What is the proper way to do this?
Best regards
Ole
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.
>
&g
o way to
clearly specify this as a build condition. Just ignoring this and let
them fail doesn't look very smart.
Best
Ole
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
age by just disabling the failing tests.
> 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.
This is only true if the bug is noticed, which is not always the
case.
Best
Ole
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 including the
This HTML is also generated by a script, so not directly downloadable.
Since Gitlab is one of the standard providers, there may be a good
solution to get the correct tarball? Or is there a better way for
upstream to provide a complete tarball than the one chosen here?
Best regards
Ole
e what the canonical way is to detect whether a
debian build runs. How should one solve this?
Best regards
Ole
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 not work
sacore&ver=3.2.1-1
shows the build failures for the same package that compiled well on
x86_64 caused by differences in the symbols table.
How should one handle this?
Best regards
Ole
d as "installed
as dependency of sextractor", and when sextractor is going removed,
source-extractor is marked for autoremoval (resp. removed directly when
using aptitude, #945192).
How can I handle this correctly?
Best regards
Ole
t disable dh_dwz?
Cheers
Ole
er.
I am wondering whether this applies here, given the large number of
packages which don't compile.
Best
Ole
ever sounds that somewhere a
small integer was assigned to the pointer, so I would try the sanitizing
stuff first.
Cheers
Ole
Andreas Tille writes:
> Hi,
>
> as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
> and buster. I've tested in stretch (gcc 6.3) and the
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
t also a lot of old
cruft. I though that this would be removed automatically?
So what is the correct way now to get the package removed?
Best regards
Ole
[1] https://wiki.debian.org/ftpmaster_Removals
raf
which is all correct, but shouldn't be an excuse to block the migration,
right?
Best regards
Ole
roblem? Or need I to upload an updated
python-astropy package (with the Python 3 content removed) first? How
should one then handle their reverse dependencies?
(The question whether it is useful to have both python 2 and python 3 is
discussed in the d-python mailing list.)
Best regards
Ole
Hi Paul,
Paul Wise 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 C for arches with no
ossible archs for python3-pyraf (by
explicitly setting the arch list and/or build-depending on iraf), but
this would not require the removal of the packages already build.
And, in principle the dependency should work across archs (f.e. for
x32). But why does it not work with the specification above?
Best regards
Ole
npy (from
0.7.9-1)".
How can I get rid of that? 0.7.9-1 is in the Debian archives, but
neither part of testing, nor of unstable. It would however useful to
keep this version, f.e. for use in snapshots.d.o.
Best regards
Ole
at, so,
> dunno. :)
I am in contact with the Fedora astro guy, so in any case I will discuss
with him. But my fork is meant to have a chance to be included upstream,
so I will not do things that where I know they don't get accepted.
Thank you very much for your patience and your good explanations! I feel
now that I understand the multiarch idea a bit better (well, hopefully).
Best regards
Ole
Hi Guillem,
thanks for the quick answer.
Guillem Jover 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_ variants are for canadian cros
is not intended for runtime, but for
package build/development.
So, how can I canonically (ideally from C) retrieve a sorted list of
supported multi arch paths at runtime? Or is there another good way to
solve this? I would think it is a standard use case for multi arch,
isn't it?
Best regards
Ole
Hi Andrey,
Andrey Rahmatullin 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.org/transitions/htm
wondering what prevents ocaml (and its dependencies) from migrating?
Best regards
Ole
R: Command failed (status=100): ['chroot',
'/srv/piuparts.debian.org/tmp/tmpivwAUi', 'apt-cache', 'show',
'postgresql-pgsphere=1.1.1+2017.08.30-1']
E: No packages found
What does piuparts want to tell me here? And what is wrong with the
package?
Best regards
Ole
ake that I have to use "export QT_SELECT = 5" in
d/rules; but what are then my required build dependencies? Just
qtchooser? Or do I need to install any qt5 development package as well?
Best regards
Ole
Hi Nils,
Niels Thykier writes:
> Ole Streicher:
>> Andrey Rahmatullin 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 in the
> referenced bug (#824169). The situation in su
Andrey Rahmatullin 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)
> https://release.debia
check
https://release.debian.org/testing/freeze_policy.html if update is
needed)
* Piuparts tested OK - https://piuparts.debian.org/sid/source/c/cpl.html
* Not considered
The freeze URL above speaks about the Buster freeze, but isn't that a
bit early?
Best regards
Ole
Hi Paul, Christian,
Christian Seiler 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 the signature should
it by default.
What is the preferred way to included the upstream signature?
Was there some discussion about this in debian-devel that I missed?
Best regards
Ole
Gert Wollny 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
>> changed.
> One way to make dh_str
ge?
When I just use the existing "strip" command, the debugging symbols just
get removed, and also, how does dh know that it shoud build a debug
package if it does not know that it contains a shared lib?
Best regards
Ole
ded -shared -o plplot_octave.oct
CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
-Wl,-rpath,/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/src:
../../src/libplplot.so.14.0.0 -loctave -loctinterp
Best regards
Ole
not be
changed.
Best regards
Ole
Paul Wise 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...
>
>
t; You always install using fakeroot.
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...
Best
Ole
James Cowgill 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 behaviour myself - Ole Streicher
&
Andrey Rahmatullin 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 migrate. None
time, other packages migrate, like python-astropy which was
uploaded at the same time:
https://tracker.debian.org/news/831295
What is the cause for sunpy and why is nothing displayed in the
mentioned links?
Best regards
Ole
are probably things that
> uscan needs to support. There may be bugs for them, please check and
> if not, file new ones.
I will have a look; however it may be faster to ask upstream to have a
better supported url.
Best regards
Ole
k/pub/star/stilts/v([\d\.\-]+)/ stilts_src.zip
but it doesn't work; basically it adjusts upstream version to be 1:
uscan info: Newest upstream tarball version selected for download
(uversionmangled): 1
How can I get this right?
Cheers
Ole
, and manually installing python-pyvo also works
on both distributions.
Could someone decrypt the piuparts log please?
Best regards
Ole
the fact, that the first release of package
was errornously done with "Arch: any" instead of the correct "Arch:
all". This was fixed with the current version.
How do I get rid of this excuse?
Cheers
Ole
Paul Wise 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 [...]
Is there a rea
Sean Whitton 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
>> prefers strong privacy (no defaul
orities are our users and free software" point in the Social
Contract, which is very general and interpretable. The policy seems to
be silent about this. Did I just not look careful enough?
Cheers
Ole
?
> Your emails are getting eaten.
> https://lists.debian.org/debian-devel/2016/11/msg00281.html
> https://lists.debian.org/debian-devel/2016/11/msg00282.html
No, they don't. The two mails you refer to were manually (re-)sent
(bounced) by me, not by the bug system (check the "Resent-From:"
header).
Cheers
Ole
Paul Wise 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 this in that specific f
Christian Seiler 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 would be an additional plus,
to put correct time on astronomical registrations, so it is
most important to have them once they are effective. Having them in
advance would be an additional plus, however, since f.e. a computer may
be disconnected during/after the observation, if that happens on a place
without internet connection.
Best regards
Ole
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
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
Ben Finney writes:
> Ole Streicher 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 ‘tzdata’.
>
> So I think I don't understand. What
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"
>> packag
onal) update service.
How should the update service work? Can it just overwrite the existing
files? How one should handle if an update (with possibly older data) in
installed to not downgrade the data?
Is there any experience with that?
Best regards
Ole
63.html
That is just the upload message. An acceptance message is still missing.
> dak is slow today, due to something that broke it.
>
> TLTR; too late!
Hmm, what is this additional step between upload and acceptance? Can I
cancel it there?
Best
Ole
wrong here?
Best regards
Ole
about rc-2+repack? A matter of taste but I'd call this somewhat less
> ugly.
I already uploaded...
FYI, the bug is https://bugs.debian.org/840002
Best regards
Ole
Mattia Rizzolo writes:
> On Fri, Oct 07, 2016 at 12:26:09PM +0200, Ole Streicher wrote:
>> Santiago Vila 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 &&
Santiago Vila 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 best way I don&#
ly thought that the "+" is chosen because it
will not interfere with the upstream versioning?
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?
Best regards
Ole
hat the function is actually completely
unused and may be just removed. It is probably just a remnant from some
earlier universe (the code contains a huge legacy codebase).
Thank you!
Best regards
Ole
ould forward it to upstream as
well)?
Best regards
Ole
Sergio Durigan Junior 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 compressed using the supported
>
Paul Wise 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" script would then just create a
Sergio Durigan Junior writes:
> On Saturday, July 16 2016, Ole Streicher wrote:
>
>> 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, usc
ly, the package is just downloaded and then processed
further by other tools (gbp import-orig) or untarred manually.
I still don't get the reason for the other stuff that uupdate does. But
thanks for the script; I'll use it ;-)
Best regards
Ole
8
--debug does not show more here.
What is wrong here? I thought that mk-orig.tar.gz should be called only
when it is a tar archive?
Best
Ole
dependency chain; locally everything
works well.
What could cause this problem and how should one solve it?
Best regards
Ole
but is there a way to get around this
*and* keep determinism at the same time? I don't want to rewrite the
whole Makefile logic here, however.
Best regards
Ole
Paul Wise 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.
>
> Since the SONAMEs are differe
Hi Paul,
Paul Wise 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 that pgplot5 can be remo
shall I change something?
If you want to review the package, see [2]
Best regards
Ole
[1] https://bugs.debian.org/649602
[2] https://anonscm.debian.org/cgit/debian-astro/packages/giza.git
uot;g++" package, but how do
I specify the corresponding stdc++ lib? Using libstdc++-5-dev is not
nice since it will break if the default gcc switches to version 6 (and
also if on some backport version 4 is required). Or is the correct
libstdc++-dev package automatically installed with g++?
Best re
ary names as they are, and
use the formally created names:
libcasa-python32 for the Python 3 variant, and
libcasa-python2 for the Python 2 variant.
Cheers
Ole
but
a normal shared library that should be covered by the standard Debian
Policy.
Cheers
Ole
h shared and static library
> without doing to much tricky things.
For the common case, I see no real reason to include both; having just
the dynamic libs and the header is enough, IMO.
The only use case I could imagine is to create an executable that can
run outside of Debian.
Best
Ole
have more development
>> transparency than MooseFS ever had.
> And in case of file system it is not good idea.
Could you explain that a little bit more please?
Best regards
Ole
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 python-astropy-helpers=1.1~b1-1").
Best regards
Ole
ree/?h=experimental
What could be the cause that the dependency is not satisfied from
experimental here?
Best regards
Ole
Tomasz Buchert 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 discussion helped:
union-type=overlay
Cheers
Ole
NU/Linux) is has no aufs:
$ grep aufs /proc/filesystems
$ find /lib/modules -name aufs\*
$
Why is aufs gone, and what could I do for replacement?
Best regards
Ole
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
Sebastiaan Couwenberg 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 the empty default value for r
gov/FTP/software/lheasoft/fv/fv(.+\..+)_src\.tar\.gz
now always detects a new version 5.4+dfsg, even if that is already in
debian/changelog.
Best
Ole
Adam Borowski 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.
>>
Jakub Wilk writes:
> * Ole Streicher , 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
result...
* Since the download code if DFSG-Free, the downloader goes to contrib,
independently of the copyright of the data, right?
Best regards
Ole
1 - 100 of 242 matches
Mail list logo
