Re: RFS: tk-table

[Olе Streicher]

"Joseph R. Justice"  writes:
> I would suggest that a more obvious and natural fit for a maintenance
> home for this package would be:
>  Debian Tcl/Tk Packagers - mailto:pkg-tcltk-de...@lists.alioth.debian.org
>  QA Page - 
> http://qa.debian.org/developer.php?login=pkg-tcltk-devel%40lists.alioth.debian.org

I forwarded my review request to the tcl-tk mailing list. If they ask me
to move the whole stuff to debian-tcltk, I'll do that. However, since I
am not a tcl/tk developer at all, I would not like getting a member of
this packager team.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzpqeeietl@news.ole.ath.cx

Re: RFS: tk-table

[Olе Streicher]

Andrew Shadura  writes:
>> Depends: ${tcl:Depends}, ${tk:Depends}, ${misc:Depends},
>> ${shlibs:Depends}
> For that to work properly, you have to call tcltk-depends during
> package build process.

How do I do that?

> Tcl manpages need to be installed within section 3tcl or 3tk, not 3.

OK, I'll change that.

> Also, why compat level 5? If you used 7 or later, dh_installchangelogs
> would automagically pick the upstream-supplied changelog up.

I just copied the template from another package. I'll change that.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hazqs0op@news.ole.ath.cx

How to migrate to testing

[Olе Streicher]

Hi everyone,

I recvently adopted a package (sextractor) which was uploaded to
unstable 11 days ago. The previous version is really old (~ 6 years) and
had a few bugs.

The problem is now that the new version depends on some packages that
are still not available everywhere (libatlas-base-dev), and it also
fails to build on mips and mipsel (when running the unit test of the
package). If I interpret the "testing migration" section of the PTS
correctly, this hinders the package to enter testing.

So, what should I do now? The new version is definitely useful, even if
it is not available on some platforms. And how can I debug the problems
occurring in the unit tests on mips/mipsel? The log output is not really
helpful here (timeout termination on mips, sigbus on mips). Are there
machines available to run some debugging?

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz8vkx5t1l@news.ole.ath.cx

Re: How to migrate to testing

[Olе Streicher]

Jakub Wilk  writes:

> * Arno Töll , 2012-01-24, 11:48:
>>> The problem is now that the new version depends on some packages that are
>>> still not available everywhere (libatlas-base-dev),

> Like where? (Presumably you meant s/depend/build-depends/.)

You are right here. However, the binary would depend from
libatlas3gf-base, which is also not available on these platforms.

>> File a ftpmaster removal bug (ANAIS - architecture not in source) of
>> outdated architectures in unstable for your package. Once they did, your
>> package can migrate again [2].

> Err. Removing binary packages should be only done a last resort.

> Also, ANAIS means "architecture (is) not allowed in (Architecture field in)
> source (package)". It _does not_ mean "the package is out of date on this
> architecture".

I already filed the RM bug. However, what is be the preferred solution?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz1uqp5ncr@news.ole.ath.cx

Re: How to migrate to testing

[Olе Streicher]

Jakub Wilk  writes:

> * Olе Streicher , 2012-01-24, 12:52:
>>>>> The problem is now that the new version depends on some packages that are
>>>>> still not available everywhere (libatlas-base-dev),
>>>Like where? (Presumably you meant s/depend/build-depends/.)
>> You are right here. However, the binary would depend from libatlas3gf-base,
>> which is also not available on these platforms.

> "These" meaning what?

armhf and s390x.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzwr8h4882@news.ole.ath.cx

Re: How to migrate to testing

[Olе Streicher]

Jakub Wilk  writes:
> * Olе Streicher , 2012-01-24, 13:04:
>>>>>>> The problem is now that the new version depends on some packages that
>>>>>>> are still not available everywhere (libatlas-base-dev),
>>>>>Like where? (Presumably you meant s/depend/build-depends/.)
>>>> You are right here. However, the binary would depend from
>>>> libatlas3gf-base, which is also not available on these platforms.
>>>"These" meaning what?
>>armhf and s390x.
>
> Oh, you don't need to worry much about these. They are not release
> architectures and they don't affect testing migrations.

The main problem is that on the mips and mipsel architectures the
packages compile but their unit tests fail - timeout on mips, and
segfault on mipsel. The previous packaged version still didn't come with
unit tests. I informed the upstream author, but they probably more
concentrate on common platforms.

I think, for practical reasons, one would not use sextractor on a MIPS
machine yet, because it needs some processing power, so removing these
architectures until a fix is available would be a better alternative
thant using of a 6-year-old, buggy version (which never passed this kind
of unit-test).

How should I proceed here?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzsjj544i5@news.ole.ath.cx

Re: How to migrate to testing

[Olе Streicher]

Joachim Wiedorn  writes:
> Jakub Wilk  wrote on 2012-01-24 18:14:
>> Does the test suite involve heavy floating-point computations? Two of 
>> our mips buildds, corelli and lucatelli, doesn't have FPU, so it 
>> wouldn't be surprising if they couldn't run such a testsuite in a 
> I have seen in some packages that tests were disabled because of some
> problems. So my idea for armhf and s390x is to disable only tests needing
> these floating-point computations.

For armhf this would not help since there are some preconditions not met
(the atlas package is missing). For mips, however: yes, this is a
package that does *heavy* computation. Running it on a non-FPU coimputer
will take long times.

When I could confirm that the bug isn't latent in other architectures, I
could just switch off the testing in mips and mipsel. 

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwf4hgb2@news.ole.ath.cx

Renaming file names because of conflicts

[Olе Streicher]

Hi,

one of my packages has conflicts with file names in /usr/bin, and I am
convinced to change this.

The question is now, where is the right place to do this? Shall I do
something like

overwrite_dh_movefiles:
dh_movefiles
mv debian/wcstools/bin/imcat debian/wcstools/bin/imcatalog
mv debian/wcstools/man/man1/imcat.1 debian/wcstools/man/man1/imcatalog.1

and additionally patching the manpage?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uqlgehx@news.ole.ath.cx

Packaging source from a git repository

[Olе Streicher]

Hi,

I need create a package from a git repository (specifically
libraries/sla from ). 

What are the best options to do this?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzmx8u3jxs@news.ole.ath.cx

Re: Providing a non-free alternative to a free package

[Olе Streicher]

Gergely Nagy  writes:
> If it is obfuscated, then it is most probably not the preferred form of
> modification (and not the real source, but something derived from that),
> thus, them being GPL'd is invalid, and it's not even fit for non-free,
> as far as I see.

This is something I have to discuss with the upstream author (who also
sells the unobfuscated version). He probably would then make a specific
license which would allow its distribution, but he is not willing to put
the original source code under GPL.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzvcnh1u8b@news.ole.ath.cx

Re: Providing a non-free alternative to a free package

[Olе Streicher]

Gergely Nagy  writes:
> debian-de...@liska.ath.cx (Olе Streicher) writes:
>> For example "saods9" would use slalib as a shared library, and I want to
>> git the user a choide to run it either with the free, or with the
>> non-free version.

> Are the two libraries actually ABI compatible? Somehow I doubt that, but
> I might just be too sceptic when it comes to non-free software.

They come from the same author, so I would assume (and test :-) ) that
they are compatible.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzehu51ple@news.ole.ath.cx

Re: Providing a non-free alternative to a free package

[Olе Streicher]

Adam Borowski  writes:
> Is slalib the contents of libraries/sla/ in the repository you linked
> to?

Yes.

> If so, it appears the current upstream is not the sole copyright
> holder, and there are many other contributors dating from 2004 for
> sla, and 1989 for the project as a whole (counting only versioned
> history).  

The slalib goes back to 1989, and is written by P.T.Wallace. He wrote
two versions of the library, one in Fortran, and another in C. The
Fortran version he put under GPL, while he sells the C library. On
request request he offers an obfuscated C version for free (as in Beer),
with a purpose-limited, non-commercial license. 

The starlink project itself (where the free version of the library is
part of) dates back to 1980.

> This means, it is illegal to distribute the obfuscated version for
> anyone (including current upstream), and anyone who buys the
> unobfuscated one can pass it further under GPL.

Since the obfuscated version comes from the author, he is legal to
distribute it under any license he wants.

However, after comparing some of the obfuscated files with the Fortran
versions, I think that the C version is not superior to the Fortran
one. The main disadvantage the (Standard) Fortran version has is that
the local variables of Fortran functions are usually stored in a
statically allocated memory which makes the library not threadsafe, but
thread safety is needed for its use. This is solved upstream by using a
mutex lock around each library call, which slows down execution. For
Debian, the gfortran compiler offers a "-frecursive" flag which puts
local variables on the stack, and therefore does not have this problem. 

As long as there are no other important advantages of the non-free
version, I would not plan to package it; however I would like to create
the free Fortan version in a way that it may be replaced by its non-free
C variant.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzy5sczatq@news.ole.ath.cx

Mentors.debian.net incoming queue

[Olе Streicher]

Dear mentors,

I wonder how the incoming queue of mentors.debian.net is processed?
Yesterday, I tried to re-upload my package (tk-html3) after removing the
old package, and it did not arrive in the package list yet; I also did
not get a mail response. The package list, however, contains packages
that were uploaded after mine, so the processing queue seems to work. I
repeated the upload today, but without success.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzaa3qdvhn@news.ole.ath.cx

l18n?

[Olе Streicher]

Dear mentors,

I am currently working on a Tcl/Tk package (saods9;
) which has a "msg" subdirectory
containing translations into a handful languages:

$ ls -l msgs/
insgesamt 308
-rw-rw-r-- 1 ole no 39129 2012-04-11 14:01 da.msg
-rw-rw-r-- 1 ole no 38259 2012-04-11 14:01 de.msg
-rw-rw-r-- 1 ole no 41958 2012-04-11 14:01 es.msg
-rw-rw-r-- 1 ole no 37107 2012-04-11 14:01 fr.msg
-rw-rw-r-- 1 ole no 76973 2012-04-11 14:01 ja.msg
-rw-rw-r-- 1 ole no 39144 2012-04-11 14:01 pt.msg
-rw-rw-r-- 1 ole no 25965 2012-04-11 14:01 zh.msg

They are quite small. Shall I keep them in the main package, or would it
be useful to create individual i18n packages out of them? And, if yes,
is this as easy as

* creating a section in debian/control
---8<--
Package: saods9-l10n-de
Architecture: all
Depends: ${misc:Depends}, saods9 (= ${binary:Version})
Description: German language package for saods9
 DS9 is an application for astronomical imaging and data visualization.
 .
 This package contains the localization of saods9 in German.
---8<--

* patching the rule

---8<--
override_dh_auto_install:
dh_auto_install
for LOCALE in da de es fr ja pt zh ; do \
dh_install $(CURDIR)msgs/$${LOCALE}.msg \
  $(CURDIR)/debian/saods9-l10n-$${LOCALE}/usr/share/saods9/msgs/ \
done
---8<--

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzaa2fg1mo@news.ole.ath.cx

Re: l18n?

[Olе Streicher]

Thibaut Paumard  writes:
> At most, I would split the package in an arch-dependent and an
> arch-independent package, and that's assuming ds9 has even more arch
> indep data than just those messages (say, if the data reaches ~2MB).

In my case, the architecture independent data (in /usr/share) are really
quite large: ~10 MB. However, most of this (~ 7MB) goes into the html
help (containing many images --> bad compression), which is more-or-less
indepenendent of the package itself. Therefore, I am planning to
separate the documentation into a saods9-doc package and make the saods9
package dependend on the -doc. 

Would this be reasonable? I would allow a (usable) installation of the
documentation without the need to install the whole package (and its
dependency nightmare) - for whatever reason one would need this.

Regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz62d3fzse@news.ole.ath.cx

Re: l18n?

[Olе Streicher]

Thibaut Paumard  writes:
> So you have :
>
> - 7MB documentation;
> - 3MB other ach-indep data;
> - some arch-dep data (the amount is not much relevant :-) )
>
> Is the doc necessary for reliable use of the package, or is is just that
> you get an error message when clicking Help->User Manual?

In the moment, also the program logo is taken from the doc which is used
in the "about" message. Both "Help" and "About" are broken if the doc
package is not there -- and they mess up the application (they create
unclosable windows). So I think the easiest solution is to create a
strong dependency.

> If it makes sense to not install the documentation, I would split in three:

I see a potential use case in installing the documentation, but not the
program (someone wants to browse the doc on a machine that cannot
install all dependencies of ds9, f.e. a ebook-reader based on Debian ;-) 
-- however I have no feeling how realistic this is.

Also, with some additional patching, I would probably just be able to
disable the help if the directory is not there, and make the logo
optional (the package needs many patches anyway; one more would not
count). Then, ignoring the doc would allow to have a smaller footprint;
however the program is only used on machines where a few megabytes do
not matter at all.

Regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzty0nek3b@news.ole.ath.cx

Changing SONAME in library version

[Olе Streicher]

Dear mentors,

I am the maintainer of the package "cpl". Upstream just released a new
version 6.0 and changed the SONAME for the built libraries from 12 to
20. So, the source now builds a package "libcplcore20" instead of
"libcplcore12". There are a few dependencies of other packages from
libcplcore12, which I all maintain myself (esorex and python-cpl).

The problem is now that I get migration excuses like

"out of date on i386: [...], libcplcore12, [...] (from 5.3.1-1)"

which I don't know how to handle. What is the usual way to get rid of
these? 

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz8vh4az2d@news.ole.ath.cx

Re: Changing SONAME in library version

[Olе Streicher]

Tobias Frost  writes:
> For soname changes you probably wanted to set up a transition.
> http://wiki.debian.org/OngoingTransitions
> (Usually that should be done before the upload to unstable) The
> transistion page helps a lot to keep track of the transistion, so you
> should ask the release team to set one up for you.
>
> The release team will then also schedule the binNMUs for you.

I still not understand: why do I need a binNMU? Only two packages depend
on the shared library, both packaged are maintained by myself and I have
new versions of them in sync with the library. Even if the latter would
not be the case -- since I am the maintainer, I could just upload a new
(unchanged) release to trigger recompilation.

By reading [1], I could not completely follow how the transition is
usually done, who is involved etc. I already have filed a transition
bug. The release team will now setup a transition page, right? What
should I do after this happened? And how is my sponsor involved in the
whole process?

Best regards

Ole

[1] http://wiki.debian.org/Teams/ReleaseTeam/Transitions


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz1umvb0g6@news.ole.ath.cx

(un)patching patched files

[Olе Streicher]

Dear Mentors,

For a package [1], I have to patch one file (Makefile.am) twice: once
from debian/patches, and the other times from debian/rules. The patch in
debian/patches is needed to bring allow the use of a standard automake
(upstream uses a patched version), while the patch done from
debian/rules contains a rename of all libraries built. It is done in the
following way:

8<-
override_dh_autoreconf:
sed s/libast/libstarlink_ast/g -i Makefile.am
AUTOMAKE="automake --foreign" dh_autoreconf

override_dh_clean:
sed s/libstarlink_ast/libast/g -i Makefile.am
dh_clean
8<-

The problem is now, that debuild finally calls "dpkg-source
--after-build", which undoes debian/patches before (or without) calling
dh_clean. Since debian/patches works with the original names (libast),
undoing the patches fails.

What is the proper solution to deal with this? Converting the patching
from debian/rules to a debian/patches patch is not a good solution,
since the library names are heavily used in the whole Makefile.am, and
the resulting patch would be huge, complicated (understanding the lines
in debian/rules is much easier) and fill fail on each small change.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzlil09yqh@news.ole.ath.cx

Re: (un)patching patched files

[Olе Streicher]

gregor herrmann  writes:
> Maybe try to move the second sed call from _clean to _autoreconf
> directly after the dh_autoreconf invocation?

I've tried this -- this triggers a re-creation of Makefile.in with the
original names, which are then errornously used to build the package.

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzhavo9xov@news.ole.ath.cx

Re: (un)patching patched files

[Olе Streicher]

Gergely Nagy  writes:
> The patch in debian/patches will be large, possibly complicated and
> whatnot, but you can explain how it is created in debian/README.source,
> and live happily ever after.
>
> There are cases where a bit of ugliness is acceptable. This is one such
> case.

I still do not see what one would gain with this compared to the
debian/rules based solution. In principle, I would just need a target
that is applied just before "dpkg--after-build" is called.

I have the same problem in another package: here, an executable is going
to be renamed, and therefore also the manpage. Additionally, the manpage
needs a patch. Since the manpage is renamed, unpatching it after build
fails. Also for this case I would need a place to undo the renaming just
before "dpkg--after-build" is called.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzd36c9td9@news.ole.ath.cx

Re: (un)patching patched files

[Olе Streicher]

Hi Thibaut,

Thibaut Paumard  writes:
> If you use a patch system, you should use it to do the patching

OK, so I created a small shell script what creates/updates a file
in debian/patches.

However, now I have another problem: when I run 

debuild
debuild clean

I get an error since "debuild clean" does not apply the patches, and
"clean" calls (indirectly) autoreconf -- and the unpatched Makefile.am
resp. configure.ac (which is processed there) don't work with the
standard autoconf.

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz8vh09p8x@news.ole.ath.cx

Re: (un)patching patched files

[Olе Streicher]

Thibaut Paumard  writes:
> Can you not override clean to be a no-op or at least not trigger
> autoreconf if the patches have not been applied?

Overriding with no-op doesn't help since then my directory is still
cluttered with all the trash from the build.

To me, this problem sounds like a bug in devscripts: debuild (or
dpkg-package) should consistently handle the patching; either debuild
should *not* revert the patches, or debuild clean should apply them
first (and may or may not revert them afterwards).

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz4nro9nu2@news.ole.ath.cx

Re: (un)patching patched files

[Olе Streicher]

Thibaut Paumard  writes:
> Have you tried debuild -tc? It ought to call debian/rules clean before
> unapplying the patches. IMHO, it should be the default.

I agree. Since 

debuild
[...]
debuild clean

is recommended in the docs [1], I would think it is a bug.

Cheers

Ole

[1] http://www.debian.org/doc/manuals/maint-guide/build.en.html


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzzk9g86w4@news.ole.ath.cx

Re: Changing SONAME in library version

[Olе Streicher]

Dear mentors,

could someone give me a hint on how to proceed here?

debian-de...@liska.ath.cx (Olе Streicher) writes:
> Tobias Frost  writes:
>> For soname changes you probably wanted to set up a transition.
>> http://wiki.debian.org/OngoingTransitions
>> (Usually that should be done before the upload to unstable) The
>> transistion page helps a lot to keep track of the transistion, so you
>> should ask the release team to set one up for you.
>>
>> The release team will then also schedule the binNMUs for you.
>
> I still not understand: why do I need a binNMU? Only two packages depend
> on the shared library, both packaged are maintained by myself and I have
> new versions of them in sync with the library. Even if the latter would
> not be the case -- since I am the maintainer, I could just upload a new
> (unchanged) release to trigger recompilation.
>
> By reading [1], I could not completely follow how the transition is
> usually done, who is involved etc. I already have filed a transition
> bug. The release team will now setup a transition page, right? What
> should I do after this happened? And how is my sponsor involved in the
> whole process?
>
> Best regards
>
> Ole
>
> [1] http://wiki.debian.org/Teams/ReleaseTeam/Transitions


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzsjf386oi@news.ole.ath.cx

Re: Changing SONAME in library version

[Olе Streicher]

Hi Thibaut,

Thibaut Paumard  writes:
> Le 14/05/12 11:15, Olе Streicher a écrit :
>> could someone give me a hint on how to proceed here?
> The release team will answer your [request] soon and let you know
> whether it's OK to transition your packages. In the meantime you could
> upload them to experimental to see whether they compile and run fine.
>  [request] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671853

> As a matter of fact, the new release of CPL fails to build on most
> architectures! This is the reason for all the "out of date" excuses. In
> addition, the package was [reported] to be uninstallable:
>  [reported] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671675

I know and I am working on this. Since I don't have access to these
architectures, this is not easy. The RC bug would be simple to fix;
I just makes no sense to upload the new version unless I can get the
FTBS fixed.

Some of the "out-of-date" excuses, however, result from the SONAME
change (libcplcore12 --> libcplcore20), and I don't know hoe to handle
them. 

The CPL libraries have just two reverse dependencies: only esorex and
python-cpl depend on libcpl*. Both have new versions ready to upload, so
the new triple

cpl_6.0-2 (libcplcore20 etc.), esorex_3.9.6-1, python-cpl_0.3.6-1

could replace the current "testing" triple

cpl_5.3.1-1 (libcplcore12 etc.), exorex_3.9.0-1, python-cpl_0.3.5.1-1

without any unresolved dependencies left.

> You have two options:
>  - work on the current release to get a decent version of DS9
>in wheezy, if not the most recent;
>  - work on the transition, but it will be a lot of work and you
>are likely to miss wheezy.

DS9 (saods9) is independent of CPL. For saods9, there is just the
package "starlink-ast" not uploaded yet. Since I already asked Sylvestre
Ledru for an upload (he may be on vacation in these weeks), I am not
sure if I should/could ask someone else for the same issue or if this
may make him upset. If you like, you could anyway review the package

http://anonscm.debian.org/git/debian-science/packages/starlink-ast.git

and I would appreciate your comments and hints (as well as on the
current saods9 release).

> To work on the build failures, you will need to:
>  - read the build [logs];
>  - ask for a [guest] account on the portboxes.
>  [logs]  https://buildd.debian.org/status/package.php?p=cpl
>  [guest] http://dsa.debian.org/doc/guest-account/

Since I am still a Newbee, I would need a sponsor to do so. Would you
like, and are you already able to sponsor a guest account for me?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzobpq9ajz@news.ole.ath.cx

Re: Changing SONAME in library version

[Olе Streicher]

Hi Thibaut,

Thibaut Paumard  writes:
> Le 14/05/12 15:06, Olе Streicher a écrit :
>> Some of the "out-of-date" excuses, however, result from the SONAME
>> change (libcplcore12 --> libcplcore20), and I don't know hoe to handle
>> them. 

> As part of the transition, libcpl*12 will be removed from the archive,
> which will suppress this "excuse" (so don't worry for that yet).

Can't I remove them myself (together with the old esorex and python-cpl
versions) when they all are in unstable?

> However, I don't get the deal will libcext-dev: why is it still at 5.3.1
> whereas libcext0 has been updated to 0.6?

The cause for the RC bug is just that I accidently removed the
libcext-dev section from the debian/control file. Simply re-inserting
does the job (already done in the git repository; not uploaded yet
because of the unresolved FTBS).

Regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzk40e96mn@news.ole.ath.cx

Bug archiving

[Olе Streicher]

Hi list,

I just re-inserted a package that was removed from Debian a year ago
(saods9), and following some recommendations, I exhumated the old bugs
and set them to "fixed" in the new version.

Shall I archive them now again manually? Or is this done somehow
automatically?  What is this "archived" flag about?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz62al5d5t@news.ole.ath.cx

Re-inserting package with name change

[Olе Streicher]

Hi,

I am working to re-insert a package that was removed three years
ago. Since the package name is quite short, I also changed its name: the
package name was "fv" [1], and I changed it to "ftools-fv" [2].

As recommended, I also exhumed the bugs that were closed by the package
removal. They will be fixed by the new package; the changelog contains
the appropriate "Closes: #259548" entry.

However, when uploading to mentors.debian.net, the QA information
contains the error "Package closes bugs in a wrong way: Bug #259548 does
not belong to this package" [3]. 

Shall I just ignore this error? Or shall I assign the bugs to the new
(still unknown to the system) package name "ftools-fv"?

Another question is whether I need to somehow propagate the name
change. in debian/control, I have set "Conflicts: fv; Replaces: fv"
Should I also set "Provides: fv"? This would pollute the package
namespace again with a virtual package of this short name which was the
main reason to change it. 

[1] http://packages.qa.debian.org/f/fv.html
[2] http://bugs.debian.org/682205
[3] https://mentors.debian.net/package/ftools-fv

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzmx1gbp3k@news.ole.ath.cx

How to remove a package from unstable

[Olе Streicher]

Hi,

I accidently uploaded a package to unstable (python-cpl) that should
have gone to experimental. How can I remove that from unstable but not
from testing?

After reading http://wiki.debian.org/ftpmaster_Removals, I am unsure
whether the package would be removed from testing as well if I would
just file a bug report against ftp-masters.debian.org? Because of the
freeze, this would be fatal for the package.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vcbxtzw@liska.ath.cx

How to bring life into a (Tk) package?

[Olе Streicher]

Dear list,

I want to adopt the package "tktable2.9" but I found me confronted with
some problems:

1. The package name contains the version, and since the upstream version
is now 2.10, I would need to give a new name. 

2. The package was orphaned since 2008 and is removed from unstable (and
testing) now, see but #465957. However, it is still available in stable.

Is this then a new package (so that I need to write an ITP), or is it
still an adoption (and I need to write an ITA)?

3. The Debian Tcl/Tk policy states that the modules should be named
"tk-table". My package, however is called "tktable2.10" (src) and
"libtktable2.10" (binary). Is this a good moment for a name change, so
that both (src and binary) are called "tk-table" (without version
number)? If yes, how should I state the dependencies? In the moment,
they are:

Replaces: tktable, tktable-dev, libtktable, libtktable-dev
Conflicts: tktable, tktable-dev, libtktable, libtktable-dev

since some time ago (~7 years from now) the versioned package was
introduced. What is the best way to fix this?

On the build side, I find the policy quite confusing: It says "Build
dependencies for Tcl/Tk dependent packages must be declared for every
Tcl/Tk version, that the package is built for. In order to build for a
specific version, add the versioned Tcl/Tk packages dependencies; it is
generally better and recommended depending on the appropriate default
packages with an eventual strict or relaxed versioning."

Since the package can be build for 8.4 as well as for 8.5, what should I
put into the Build-Depends and Depends? The old package used 

Build-Depends: [...] tcl8.4-dev, tk8.4-dev

Depends: [...] tcl|tcl8.5|tcl8.4|tcl8.3, tk|tk8.5|tk8.4|tk8.3

Is it OK to just replace that with the unversioned relationships?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzzke1i12j@news.ole.ath.cx

Re: How to bring life into a (Tk) package?

[Olе Streicher]

Andrew Shadura  writes:
> Tcl API is stable enough to just depend on the lowest version it builds
> against; however, it's better to build-depend on unversioned packages
> (eg tcl and tk instead of tcl8.5 and tk8.5) but use versioned
> dependencies on unversioned packages for your binaries (like, tcl
> (>=8.5.0)). 

Since it also builds in 8.3 and 8.4, should I put (>= 8.3.0) here?

> Also, please use tcltk-depends to put the correct versions into
> Depends fields.

How do I do this? My control file is like

-8<
Source: tk-table
[...]
Build-Depends: debhelper (>= 7.0.50), dh-autoreconf, tcl-dev (>= 8.3.0), tk-dev 
(>= 8.3.0)
[...]

Package: tk-table
Section: libs
Architecture: any
Depends: ${tcl:Depends}, ${tk:Depends}, ${misc:Depends}, ${shlibs:Depends}
Provides: libtktable2.9
Replaces: libtktable2.9
Conflicts: libtktable2.9
Description: [...]
-8<

but while packaging I get

   dh_gencontrol
dpkg-gencontrol: warning: Depends field of package tk-table: unknown 
substitution variable ${tcl:Depends}
dpkg-gencontrol: warning: Depends field of package tk-table: unknown 
substitution variable ${tk:Depends}

Shouldn't it be enough to depend on tcl-dev and tk-dev?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzzkdxjlrd@news.ole.ath.cx

uscan, dfsg and changelog

[Olе Streicher]

Hi,

I have a source that needs to be repackaged due to some copyright
issues. From the Mentors FAQ, I found that I should name the package
"foo-1.2.3+dfsg-1". So, I made a repacking script (should it have a
predefined name, btw?) like:

8<---
#!/bin/sh
ver=$2
orig_tar=$1
wd=mktmp -d
tar xf $orig_tar -C $wd 
rm -rf $wd/foo/non-free-part
tar czf foo-$ver+dfsg.orig.tar.gz -C $wd .
rm -rf $wd
8<---

which creates the foo-1.2.3+dfsg.orig.tar.gz file. Then I put the
following into my debian/changelog:

8<---
foo (1.2.3+dfsg-1) unstable; urgency=low

  * New package. Closes: #xx

 -- Ole Streicher   Mon, 16 Jan 2012 12:37:00 +0100
8<---

When I now run "uscan -debug -f" (to check the script), I get

uscan debug: [...]
-- Found the following matching hrefs:
   [...]
 http://foo.bar.edu/foo/foo-1.2.3.tar.gz
Newest version on remote site is 1.2.3, local version is 1.2.3+dfsg
 => remote site does not even have current version
-- Scan finished

so it obviously tries to put the +dfsg suffix to the download file.

How can I avoid that?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzhazvkcze@news.ole.ath.cx

docbase trouble

[Olе Streicher]

Hi everyone,

on my current package, lintian complains about

I: xpa-dev: possible-documentation-but-no-doc-base-registration

in the package directory, I have:

$ ls debian/xpa-dev/usr/share/doc/xpa-dev
acl.html convert.html   info.html  server.htmlxpa.pdf.gz
changelog.Debian.gz  copyright  intro.html tcl.html   xt.html
changelog.gz env.html   method.htmltemplate.html
changelog.html.gzexamples.html  name.html  users.html
changes.html help.html  oom.html   xpamb.html
client.html  inet.html  programs.html  xpans.html

and my xpa-dev.docbase says:

---8<
Document: xpa
Title: [...]
Section: [...]
Abstract:  [...]

Format: PDF
Files: /usr/share/doc/xpa-dev/xpa.pdf.gz

Format: HTML
Index: /usr/share/doc/xpa-dev/help.html
Files: /usr/share/doc/xpa-dev/*.html
---8<

I have two questions here:
1. Why does lintian complain? Both HTML and PDF are mentioned in the
docbase.

2. The changelog.html.gz was installed by dh_installchangelogs. However,
the file is referenced by help.html, so I would like to have it
uncompressed. Is there a way to instruct dh_installchangelog to keep it
uncompressed? 

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz8vl5jbb6@news.ole.ath.cx

Re: docbase trouble

[Olе Streicher]

kuLa  writes:
> On 18/01/12 15:10, Olе Streicher wrote:
>> 2. The changelog.html.gz was installed by dh_installchangelogs. However,
>> the file is referenced by help.html, so I would like to have it
>> uncompressed. Is there a way to instruct dh_installchangelog to keep it
>> uncompressed? 

> are you interested in d/changelog or upstream changelog?

This is the upstream one which comes as part of their HTML
documentation.

Best

Ole



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz4nvtjasl@news.ole.ath.cx

Changelog (Was: docbase trouble)

[Olе Streicher]

kuLa  writes:
> On 18/01/12 15:22, Olе Streicher wrote:
>> kuLa  writes:
>>> On 18/01/12 15:10, Olе Streicher wrote:
>>>> 2. The changelog.html.gz was installed by dh_installchangelogs. However,
>>>> the file is referenced by help.html, so I would like to have it
>>>> uncompressed. Is there a way to instruct dh_installchangelog to keep it
>>>> uncompressed? 

> well maybe I'm wrong but there is no word in man for
> dh_installchangelogs about gz'iping anything and now I'm quoting:
> " If the changelog is a html file (determined by file extension), it
> will be installed as
>usr/share/doc/package/changelog.html instead, and will be
> converted to plain text with html2text to generate
> usr/share/doc/package/changelog."

It seems that dh_compress is responsible for the compression. However,
if I switch this off with the rule

override_dh_compress:
dh_compress -Xchangelog.html

lintian complains with the error "changelog-file-not-compressed". 

So, do I have now the choice between a broken link in the HTML
documentation and a policy violation? Which one should I choose?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzzkdlhuhg.fsf...@news.ole.ath.cx

Hardening-check reports on hardened object

[Olе Streicher]

Hi,

For the python-astropy package [1], I have a source code [2], that is
compiled into a shared library (for a Python extension). The hardening
flags are switched on, as seen from the build log:

---8<--
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python2.7 -c 
astropy/utils/xml/src/iterparse.c -o 
build/temp.linux-x86_64-2.7/astropy/utils/xml/src/iterparse.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-Bsymbolic-functions 
-Wl,-z,relro -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 
build/temp.linux-x86_64-2.7/astropy/utils/xml/src/iterparse.o -lexpat -o 
build/lib.linux-x86_64-2.7/astropy/utils/xml/_iterparser.so
---8<--

However, lintian still reports a "hardening-no-fortify-functions", with
some reason: Running "hardening-check --verbose" gives

---8<--
[...]
 Fortify Source functions: no, only unprotected functions found!
unprotected: read
unprotected: memcpy
---8<--

Checking the source code shows that both functions are really used.
Why are they not translated into their fortified counterparts and what
should one do here? Just override lintian?

Best

Ole

[1] ITP http://bugs.debian.org/678168
[2] 
https://github.com/astropy/astropy/blob/master/astropy/utils/xml/src/iterparse.c


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzwqu32wkf@news.ole.ath.cx

Lintian says "package-contains-ancient-file"

[Olе Streicher]

Hi,

I am currently working on the (re-)packaging of the "IRAF" astronomical
package [1]. This is a huge package with old roots -- the history goes
back to the early eighties.

Therefore, the package contains a couple of files which are quite old --
some help files, sources, documentation etc. date 1983 and 1984. This
leads to the Lintian *error* shown in the subject. Although I think it
is reasonable to overwrite this tag (the files actually *are* that old,
and they are still part of the package), I am a bit concerned by the
Lintian explanation "Your package will be rejected by the Debian archive
scripts if it contains a file with such a timestamp".

Searching the policy, I could not find a point that would speak against
using old time stamps. Even more, the policy asks me to *keep* the time
stamps:

| 4.7 Time Stamps
| Maintainers should preserve the modification times of the upstream
| source files in a package, as far as is reasonably possible.

I would also feel a bit bad with just "touch"ing these files, since the
age may be an indicator to evaluate the contained information.

So, is it reasonable just to overwrite this tag, or will I then face to
a package reject? What is the reason for this tag?

The package is still heavily used in astronomy and definitely worth
packaging. It already was in Debian until 2004 but had to be removed due
to license restrictions (which are solved now).

Best regards

Ole

[1] http://bugs.debian.org/690531


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vc65x4vv@news.ole.ath.cx

Multiarch: how to get arch in runtime?

[Olе Streicher]

Hi,

I am currently creating a package [1] that I want to have Multiarch
enabled. The program is started via a link to a shell script (for
historic reasons, this is C shell):

/usr/bin/iraf-cl -> /usr/share/iraf/unix/hlib/cl.csh

where the shell script contains some environmental settings, and then
shall finish with execing the "raw" binary:

[...]
setenv iraf_b /usr/lib/x86_64-linux-gnu/iraf/
exec ${iraf_b}bin/cl.e

(${iraf_b} is also used internally to find other libraries and
executables) My problem is now, how to find out the path here? I could
do a 

setenv iraf_b /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/iraf/

but, I thought dpkg-architecture to be a development helper and not a
common-user tool.

How could I solve this in a clean way?

Best regards

Ole

[1] IRAF, http://bugs.debian.org/690531


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz8v2q49qs@news.ole.ath.cx

Re: Multiarch: how to get arch in runtime?

[Olе Streicher]

Adam Borowski  writes:
> But, what is the reason you want the executable to be multiarched for? 

In my case you are right. However, in the general case if think there is
a good use case: If you have a program that uses precompiled extensions,
and you have an extension only available on a certain architecture, then
you may want to use the executable for this architecture as
well. Imagine f.e. Python and an i386-only database interface module.

Theoretically, this is the case for IRAF as well (it heavily works with
precompiled extensions); however the extensions are regular executables;
so they easily be mixed with different architectures.

To enable this, should I mark all these packages with "Multi-Arch:
foreign"? I will have potentially one package that is available for i386
only, and I'd like to have its dependency met even on a x86_64 platform.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz4nde3xqz@news.ole.ath.cx

Directories: FHS; permissions

[Olе Streicher]

Hi,

In my package, I need two directories that have the permission
"drwxrwxrwt": Users shall be able to create a subdirectory on their own
there: one is a cache area, and the other is a storage place.

The original places are /iraf/cache/ and /iraf/imdirs/, which obviously
contradicts the FHS. So, for the cache, I think /var/cache/iraf/ would
be the correct place, right? Then I have the problem that ordinary users
need to create their own subdir there in /var/cache/iraf//, and
top do this the permissions /var/cache/iraf/ should be 1777. How can I
do this? dh_installdirs always sets them to 755.

The other question is on where to move /iraf/imdirs//. Should it
go to something like /var/lib/imdirs//, or should I put it into
the users home dir ($HOME/imdirs/)?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzzjv62hpl@news.ole.ath.cx

[Repost] RFS: cpl-plugin-* [ITP] -- ESO data reduction pipeline recipes

[Olе Streicher]

Dear mentors,

Since I didn't get response since three weeks, I am reposting my
Requests For Sponsorship so that it does not get lost:

I have prepared five packages that have a similar structure and are to
be used as plugins for the "cpl" library and the "esorex" and
"python-cpl" packages. Each plugin contains the software to process
("reduce" in the astronomer's slang) the data of one instrument mounted
at the Very Large Telescope (VLT) of the European Southern Telescope
(ESO) in Paranal:

* cpl-plugin-hawki/1.8.12-1
* cpl-plugin-sinfo/2.3.3-1
* cpl-plugin-fors/4.9.23-1
* cpl-plugin-giraf/2.11.1-1
* cpl-plugin-amber/4.2.2-1

RFS:
* HAWK-I  http://bugs.debian.org/723962
* SINFONI http://bugs.debian.org/723968
* FORShttp://bugs.debian.org/723970
* GIRAFFE http://bugs.debian.org/723971
* AMBER   http://bugs.debian.org/723972

Source package URL:
* HAWK-I  http://mentors.debian.net/package/cpl-plugin-hawki
* SINFONI http://mentors.debian.net/package/cpl-plugin-sinfo
* FORShttp://mentors.debian.net/package/cpl-plugin-fors
* GIRAFFE http://mentors.debian.net/package/cpl-plugin-giraf
* AMBER   http://mentors.debian.net/package/cpl-plugin-amber

All packages are GPL and upstream developer is ESO. A common overview
for the pipelines is on http://www.eso.org/sci/software/pipelines/

The packages are all built using a common template, so reviewing all
five should be not much more work than for one.

Relevant differences between the packages:

* The copyright files are special since usually the upstream source code
is collected from several sources. I always checked where their use can
be replaced by Debian packages (like sextractor in cpl-plugin-fors).

* Dependencies differ a bit (libfftw, libwcs).

* The packages are usually accompanied with a number of files used for
calibration purposes. Due to their size, I did not always include them.
I have chosen a limit of ~10MB package size, so that calibration
packages exceeding this size will not include the files but download
them during the package installation. (cpl-plugin-amber-calib).

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytzmwmcfc73@news.ole.ath.cx

Re: [Repost] RFS: cpl-plugin-* [ITP] -- ESO data reduction pipeline recipes

[Olе Streicher]

Hi Julian,

Julian Taylor  writes:
> you put in the current maintainers of the pipelines as upstream
> authors. Can you please check with them if this is correct.  So far I
> know the support for this software is supposed to go over
> usd-h...@eso.org Also its Upstream-Contact not Upstream-Author in the
> machine readable copyright format.

I changed the field to Upstream-Contact: and put the contact address
there instead of the authors (resp. maintainers). This is in the git
yet; I will upload it in the next days to mentors.debian.net.

> Concerning the calibration data, you may be able to save significant
> amount of space by compressing them with cfitsio fpack utility. Its
> usually better than generic compression methods, at the cost that it
> can only be read by cfitsio compatible programs (which is the case for
> these pipelines).

Thank you for the hint. However, fpack is (still) not part of Debian, so
this cannot be done in the moment. The package is maintained by HEASARC
, and thanks to the current situation in
the USA the web page is unreachable.

Once they are back, I am considering packaging their stuff and then
converting the calibration data. However, I doubt that this will squeeze
all calibration packages enough so that they all fall under my
self-defined limit of 10 MB.

> PS: I still think these packages are to specific in purpose for
> Debian, so this is no offer of sponsorship.

I restarted the discussion about this a month ago in debian-science, and
the response what only positive. Feel free to bring your arguments
there. The base packages (cpl and esorex) have an popcon of ~175, which
is quite a lot compared to other astronomy packages (ds9: ~260). And the
only purpose for cpl, python-cpl, and esorex is to run these plugins, so
in my opinion it makes perfect sense to package them as well.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytziowzgb9k@news.ole.ath.cx

Watchfile (and version numbers) for a braindead scheme

[Olе Streicher]

Hi,

I want to write a watch file for the "esomidas" package, which has
download URLs like

ftp://ftp.eso.org/pub/midaspub/13SEP/sources/13SEPpl1.1.tar.gz

(12 is the two-digit year, FEB the month of the release). I have some
problems with it: 

1. What should the version number look like for Debian? 13.09.1.1?

2. How do I convert these Month names into a number?

3. How can I access the subdirectory and search there for the same name?

Upstream will not change name or directory structure at all, since the
structure is such since 15 years.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ytz38mirn0e@news.ole.ath.cx

arch-dependent files in "Multi-Arch: same" package

[Olе Streicher]

Hi,

for some of my newly uploaded packages, I got a bug report
'arch-dependent files in "Multi-Arch: same" package' [1]. The files in
question are in /usr/share/doc/.

However, these differences do not come from differences in the
architecture but from different build environments. Specifically, these
are sphinx generated files, where sphinx puts its own version number
into the HTML footer. Since it took some time for the package to enter
Debian, the prebuild (uploaded) amd64 version differs slightly from the
i386 version build by buildd.debian.org.

My question here is now how strict it is to have identical files in
/usr/share/doc even when build in a different environment (basically,
both versions are fine here). And, if it is important, how I can ensure
that these files are identical when the build tools change (causing
minimal changes in the output).

How should I proceed here?

Best regards

Ole

[1] f.e. http://bugs.debian.org/733221


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjnjvcfa@news.ole.ath.cx

Re: arch-dependent files in "Multi-Arch: same" package

[Olе Streicher]

Andreas Metzler  writes:
> Olе Streicher  wrote:
>> My question here is now how strict it is to have identical files in
>> /usr/share/doc even when build in a different environment (basically,
>> both versions are fine here).
>
> Hello,
> It is quite important. If the shared files are not binary identical
> then the two versions of the package cannot be installed together, i.e.
> multiarch functionality is completely broken.

This design seems a bit broken to me, since one cannot guarantee that a
generated file will be bit-identical if generated by different versions
of the build environment.

>> And, if it is important, how I can ensure that these files are
>> identical when the build tools change (causing minimal changes in the
>> output).
>
> I do not think there is a magic bullet. You could edit out the version
> number with sed or perl. Or perhaps there are some commandline
> switches to get rid of the differences.

It is quite usual that a generator writes its own version number into
the generated file: help2man does this, sphinx as well (which breaks my
packages), but also even (pdf)LaTeX. It seems not a good idea to patch
the generated files to revert the changes; especially since I don't know
which changes will appear there in future. For example (in my case),
sphinx changed an option in the css file from "URL_ROOT: './'," to
"URL_ROOT: '',". It is just impossible to check every possible future
change of the files in order to patch them out. So these packages are
always subject of a failure just when one tries to rebuild them later,
contradicting the stabilization of the distribution.

> Another option would be to move out the documentation to a separate
> arch-independent package.

This would be an option, as long as there is not complaint that an
arch-independent package should be generated identically regardless of
the architecture it is built on :-)

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vby7v5xg@news.ole.ath.cx

Re: arch-dependent files in "Multi-Arch: same" package

[Olе Streicher]

Paul Wise  writes:
> On Mon, Dec 30, 2013 at 3:00 AM, Olе Streicher wrote:
>> This would be an option, as long as there is not complaint that an
>> arch-independent package should be generated identically regardless of
>> the architecture it is built on :-)

> At some point we want the entire archive to be reproducibly buildable:
>
> https://wiki.debian.org/ReproducibleBuilds

This is different since it requires to produce the same binary packages
if the same build environment was used.

My case is that /usr/share/doc may differ if the build environment
differs -- and I don't see a way to avoid this as long as there are
non-trivially generated files there.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r48uvk0k@news.ole.ath.cx

dh: different dh option for -indep

[Olе Streicher]

Hi,

my package will create a separate arch-independent -doc package with
"sphinxdoc". Since therefore sphinx is not needed for architecure
dependent builds, I moved the build dependency of the package into the
Build-Depends-Indep field in debian/control:

-8<
Build-Depends: debhelper (>= 9), [...]
Build-Depends-Indep: python-sphinx
-8<

The file debian/rules, however, still has the main rule:

-8<
%:
dh  $@ --with autoreconf,sphinxdoc
-8<

which fails when I try to build with the -B option with:

dh: unable to load addon sphinxdoc: Can't locate 
Debian/Debhelper/Sequence/sphinxdoc.pm [...]

What I tried is to create special targets for all arch dependent only builds:

-8<
clean build-arch install-arch binary-arch:
dh  $@ --with autoreconf
build-indep build install-indep install binary-indep binary:
dh  $@ --with autoreconf,sphinxdoc
-8<

However, this results in dh_autreconf called twice (?) which is
considered as an error. It also looks quite ugly to me. And, if the
sphinxdoc addon would have a special cleaning routine, this would not be
called on arch-indep builds.

What is the right solution here?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3emv9dh@news.ole.ath.cx

Splitting a package

[Olе Streicher]

Hi,

to solve the problem of , split my
package into an arch-dependent part (containing the binaries) and an
arch-independent part (containing the manual pages and HTML
documentation):

cpl-plugin-fors (4.11.12+dfsg-1) 
--> cpl-plugin-fors + cpl-plugin-fors-doc (4.11.12+dfsg-2)

However, now I get a bug report  that the
new "-doc" package has files that would overwrite parts of the old base
package.

How should I solve this problem? Should I set "Conflicts" and
"Replaces:" to "cpl-plugin-fors (=...-1)" for both new packages? I am
not sure whether two packages can replace (together) the old one, or if
they then are alternatives?

I would also see the bug report describing a non-real use-case: I could
not see a reason why someone would stay with the old package but tries
to install only the -doc package, without the base package updated.

Also, the package is quite special (it contains the data processing for
a specific astronomic instrument mounted at the Very Large Telescope),
and therefore has still a popcon of zero, so not many people will
probably have it installed.

What is the optimal way to proceed here? (identical problems are with
two other packages: cpl-plugin-xsh and cpl-plugin-giraf).

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txd9xu0f@news.ole.ath.cx

Re: Splitting a package

[Olе Streicher]

Arno Töll  writes:
> Hi Ole,
> On 12.01.2014 13:30, Olе Streicher wrote:
>> However, now I get a bug report <http://bugs.debian.org/734917> that the
>> new "-doc" package has files that would overwrite parts of the old base
>> package.

> Please use Replaces in conjunction with Breaks (not Conflicts). See
> Policy §7.6.1 which explains  your use case:
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

Thank you. I should have read it.
How long should one carry this relation? Forever?
(Once the new package is in testing, the old package is not available
anymore).

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppnxxncb@news.ole.ath.cx