Bug#1080498: RFS: apt-listchanges/4.5 [ITA] -- package change history notification tool

[Andreas Metzler]

On 2024-09-22 Jonathan Kamens  wrote:
> On 9/6/24 4:36 AM, Jeroen Ploemen wrote:
[...]
> > Any particular reason for continuing to upload to experimental only,
> > now that version 4.x has been out for about a year with nothing major
> > reported in the bug tracker?
> You're correct, I believe it's time for unstable.

Hello,

imho 1055780 is a very major issue. (The new upload is supposed to
handle that.)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents

[Andreas Metzler]

On 2024-07-26 Tobias Frost  wrote:
[...]
> - usually d/changelog's purpose is to document the changes to the Debian
>   *packaging*, not to document upstream changes. See Policy 4.6. (You've got
>   your upstream changelog, that is where your upstream changes shoudl got to.
>   In this case I'd write the changelog as:

> libmobi (0.12+dfsg-1) unstable; urgency=medium

>   * New upstream release. (Closes: #1073331)
[...]

Hello,

FWIW I think that would only be a proper changelog entry if #1073331
was a "please package new upstream version"-bug. I would go for
8X--
* New upstream release.
  + Builds with libxml >= 2.12. Closes: #1073331
8X--

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1076664: RFS: netplug/1.2.9.2-5 [RC] -- network link monitor daemon

[Andreas Metzler]

On 2024-07-21 Pali Rohár  wrote:
> Hello, sorry, but I currently do not have time to start fixing others
> issues. I focused on the issue which Vincent reported that recent
> iproute2 package upgrade completely broke the netplug package.
[...]

OK, fair enough, I will take a look.

cu Andreas

Bug#1073960: RFS: libmobi/0.12+dfsg-1 [RC] -- Tools for handling Mobipocket/Kindle ebook format documents

[Andreas Metzler]

On 2024-07-11 Phil Wyett  wrote:
[...]
> Summary...

> I believe libmobi is ready for sponsorship/upload. Could a Debian
> Developer (DD) with available free time, please review this package
> and upload if you feel it is ready.
[...]

Hello,

comparing 0.12+dfsg-1 with the version currently in the archive I found
these changes:
diff -Nru libmobi-0.11+dfsg/debian/changelog libmobi-0.12+dfsg/debian/changelog
--- libmobi-0.11+dfsg/debian/changelog  2024-02-28 15:13:08.0 +0100
+++ libmobi-0.12+dfsg/debian/changelog  2024-06-17 13:34:25.0 +0200
@@ -1,9 +1,22 @@
-libmobi (0.11+dfsg-1.1) unstable; urgency=medium
+libmobi (0.12+dfsg-1) unstable; urgency=medium
+
+  * New upstream release.
[...]
+libmobi (0.11+dfsg-1.1) experimental; urgency=medium
 
   * Non-maintainer upload.
-  * Rename libraries for 64-bit time_t transition.  Closes: #1062420
+  * Rename libraries for 64-bit time_t transition.
 
- -- Benjamin Drung   Wed, 28 Feb 2024 14:13:08 +
+ -- Steve Langasek   Thu, 01 Feb 2024 09:58:53 +
[...]
diff -Nru libmobi-0.11+dfsg/debian/control libmobi-0.12+dfsg/debian/control
--- libmobi-0.11+dfsg/debian/control2024-02-28 15:13:08.0 +0100
+++ libmobi-0.12+dfsg/debian/control2024-06-17 13:34:25.0 +0200
@@ -1,8 +1,8 @@
 Source: libmobi
 Priority: optional
 Maintainer: Bartek Fabiszewski 
-Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), zlib1g-dev, 
libxml2-dev
-Standards-Version: 4.6.0
+Build-Depends: debhelper-compat (= 13), zlib1g-dev, libxml2-dev

i.e. afaict some of the changes in the t64 transition were reverted
(added Build-Dependency and actually uploaded changelog version). Could
you please change this, Bartek? - Thanks!

cu Andreas

Re: Debian versioning question

[Andreas Metzler]

On 2023-11-10 "Preuße, Hilmar"  wrote:
> On 10.11.2023 03:10, Wookey wrote:
>> I think your options are
>> 1) add an epoch (which exists to deal with this sort of problem)
>> 
> Well, would like to avoid it, if possible.

I think it is also not the right solutions, epochs are imho intended to
fix one-off errors, but this is problem recurring with every non-major
release.

[...]
>> 3) upload a 'nobbled' version number, which is often done to deal
>> with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1
>> dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $?
>> 
> You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b,
> 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal
> versioning?

>> I'd probably go with option 3 in this case. Ugly but temporary.
>> 
> Sounds like an option for now. Thanks!

I think 1.3.8-a+dfsg-1 would work and you could swith to ~dfsg with
1.3.9 like Mattia suggested:
ametzler@argenau:~$ dpkg --compare-versions '1.3.8+dfsg-8' '<<' 1.3.8-a+dfsg-1 
&& echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-a+dfsg-2 '<<' 1.3.8-b+dfsg-1 
&& echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.8-b+dfsg-3 '<<' 1.3.9~dfsg-1 && 
echo yes
yes
ametzler@argenau:~$ dpkg --compare-versions 1.3.9~dfsg-3 '<<' 1.3.9a~dfsg-1 && 
echo yes
yes

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Upload commands to debomatic-amd64

[Andreas Metzler]

On 2023-10-30 Mathieu Malaterre  wrote:
> Dear all,

> I am trying to follow documentation from:

> * http://debomatic-amd64.debian.net/

> and:

> * 
> https://deb-o-matic.readthedocs.io/en/stable/upload.html#prepare-command-files

> Which does not seems to be working for me today;

> % dcut -U debomatic jxl.commands
> usage: dcut [-h] [-d] [-f] [-c FILE] [-m MAINTAINER] [-k KEYID] [-S]
> [-O FILENAME] [-P] [-s] [-v]
> [HOST]
> {debomatic-binnmu,debomatic-builddep,debomatic-kill,debomatic-porter,debomatic-rebuild,debomatic-rm}
> ...
> dcut: error: argument
[...]
> % apt-cache policy dput-ng
> dput-ng:
[...]

Looks like you are reading docs for dput but have dput-ng installed.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: python-module packaging: builtin distutils vs python3-setuptools

[Andreas Metzler]

On 2023-10-29 Andreas Metzler  wrote:
[...]
> Looking at other Debian packages this does not look like right. However I
> have checked "python3 setup.py  install --help" and tried to look at
> python3-setuptools documentation to find the correct knob/setting to
> switch to the other layout but just could not find it.


Hmm, --root combined with --install-lib /usr/lib/python3/dist-packages
might do the trick ...

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

python-module packaging: builtin distutils vs python3-setuptools

[Andreas Metzler]

Hello,

I am trying to unbreak building of gpgme python bindings (#1054786).
The build result differs/breaks when python3-setuptools is installed.

Afaiui python3-setuptools is a newer/extended version of python's
built-in distutil (which is scheduled for removal). If
python3-setuptools the new code is used. dh-python recently has grown a
dependency on python3-setuptools, breaking the gpgme build.

An unchanged build would install to /usr/local. distutils seems to be
patched to not only support --install-layout=deb but also to use it by
default, whereas python3-setuptools supports it but does enable it by
default. That is easily fixed, however the layout still is different:

distutils installed[1] to 
usr/lib/python3/site-packages/gpg
usr/lib/python3/site-packages/gpg/constants
usr/lib/python3/site-packages/gpg/constants/data
usr/lib/python3/site-packages/gpg/constants/data/__pycache__
[...]
plus a gpg-1.18.0.egg-info directly in usr/lib/python3/site-packages/
which we shipped in dist-packages.

python3-setuptools produces[1]
usr/lib/python3/dist-packages/
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg/gpg
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg/gpg/constants
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg/gpg/constants/tofu
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg/gpg/constants/tofu/__pycache__
[...]
usr/lib/python3/dist-packages/gpg-1.18.0-py3.11-linux-amd64.egg/EGG-INFO

Looking at other Debian packages this does not look like right. However I
have checked "python3 setup.py  install --help" and tried to look at
python3-setuptools documentation to find the correct knob/setting to
switch to the other layout but just could not find it.

TIA, cu Andreas


[1] well, it used to. If I now "dpkg --purge --force-depends
python3-setuptools" it seems to install to dist-packages. 
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: uscan - inherit version number of component from main package (SVN)

[Andreas Metzler]

On 2023-10-08 Hugh McMaster  wrote:
[...]
> Try this in your d/watch file:
[...]
> # netpbm-free user guide
> opts="mode=svn, pgpmode=none, \
>   component=userguide" \
>   https://svn.code.sf.net/p/netpbm/code/userguide \
>   HEAD ignore

> 

> You want to match against HEAD to download the most recent version,
> and specify the 'ignore' keyword to avoid restricting the secondary
> tarball version.

"ignore" was the missing piece. Thanks!

> You'll probably want to adjust the userguide tarball name (not the
> symlink) with filenamemangle.

The default version (netpbm-free-0.0~svn4637.tar.xz) looks as good as
any other static string I can think of. Only $version_found_for_netpbm-free
would be a real (but minimal) improvement, but that seems to be impossible.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

uscan - inherit version number of component from main package (SVN)

[Andreas Metzler]

Hello,

I would like to convert netpbm-free to a multiple component package, one
for the main code
http://netpbm.svn.code.sourceforge.net/p/netpbm/code/release_number/
which is versioned
and the docs from
http://netpbm.svn.code.sourceforge.net/p/netpbm/code/userguide/
with HEAD as matching‐pattern.

The obvious problem is the versioning, I would like to make uscan simply use
the main version for the userguide but afaik I cannot refer to it in
uversionmangle.

I can do
uversionmangle=s/^0\.0/20.00/
to makes uscan always (well unless upstream hits 20.00) consider
userguide outdate and save it as 
../netpbm-free_${netpbm main version}.orig-userguide.tar.xz
with directory name 
netpbm-free-20.00~svn${revision}

Afaik dpkg-source will ignore the dirname anyway, so this part should not
be a problem.

Is there anything else I am missing, is there a better approach?

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Downside of using invoke-rc.d (restart|reload) on systemd?

[Andreas Metzler]

Hello,

if I would like to restart a daemon in a maintainerscript after
dpkg-reconfigure is there a downside of simply using

invoke-rc.d foo restart

instead of something like

if [ -d /run/systemd/system ]; then
# systemd
deb-systemd-invoke restart foo.service
else
# SysV
invoke-rc.d foo restart
fi

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: dh_install by file suffix

[Andreas Metzler]

On 2023-07-15 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" 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 extension:

> - *.cl, *.hd, *.men, *.par (... and some other extensions) should go to
>   the user packages

> - *.a, *.h should go to the development packages

> (the "iraf" and "iraf-noao" package differ mainly by that "iraf" collects
> them in the pkg/ subdir, and "iraf-noao" in the noao subdir).

> The main question here is: how can I do a dh_install selective by file
> suffix? Otherwise, I would need to list the (~1000) files in the "install"
> files, which is not very robust.

Hello Olaf,

dh_install(1)
  debian/package.install
[...] The format is a set of lines, where each line lists a
file or files to install, and at the end of the line tells the
directory it should be installed in.
[...] You may use wildcards in the names of the files to install.

debian/tmp/usr/lib/iraf/*.cl /targetdirfor_cl/

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Soname bumps, new binary packages - NEW/BY-HAND queue uploading?

[Andreas Metzler]

On 2022-04-06 Adam Borowski  wrote:
> On Wed, Apr 06, 2022 at 03:02:07PM +0100, Philip Wyett wrote:
> > Could someone point me to the documentation that relates to upload
> > of packages that have new binary packages i.e. name change during an
> > update? Specifically to the new/by-hand queue.

> Dunno where the docs are, but in short:

> * rename the binary package:
>   + edit debian/control
>   + mv debian/libfoo42.* → libfoo43.*
>   + "git grep libfoo42" elsewhere, just to be sure
> * [optional but strongly recommended] test the library's users
> * request a sponsored upload even if you're a DM
> * once it passes NEW, its users might need a binNMU to rebuild with the new
>   soname
[...]

Worth mentioning: An upload introducing new biary packages cannot be a
source-only upload, the binaries needs to included in the upload.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Andreas Metzler]

On 2022-01-16 Andreas Metzler  wrote:
[...]
> I will probably followup with further wishes/comments later, not today
> but hopefully in next week.
[...]

Hello Thomas,

I think there are just two thing left pre upload:

1. The upload introduces an epoch because the upstream version went from
mmdd to 2.0.mmdd. Given that the new version scheme seems to
have found acceptance in e.g. Fedora /I/ do not see a better way. Could
you ask about the epoch on debian-devel (as per policy
https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
) - TIA.

2. It would be nice to merge the changelog entries for 1:2.0.20220109-1
and 1:2.0.20220114-1, listing only the changes relative to what was yet
uploaded to Debian. (I would not consider this a must for sponsorship.)

cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Andreas Metzler]

On 2022-01-16 Thomas Dickey  wrote:
[...]
> I reviewed the test-data differences, didn't see a problem, and verified
> with cproto (which uses lex/yacc) that there are no differences.

> So I updated the debian files to combine the two (just packaging one
> "byacc" with backtracking).

Great.

[...]
> For now, I'm just working on the Debian package of the current release :-)

I will probably followup with further wishes/comments later, not today
but hopefully in next week.

cu Andreas

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Andreas Metzler]

On 2022-01-16 Thomas Dickey  wrote:
> On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote:
[...]
 
> > I would like to question the introduction of another binary package:
> > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for
> >   "byacc2" only finds links related to this RFS.

> Ultimately that's because Debian's the only place where the older "btyacc"
> is packaged.

[...]
> > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance
> > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward
> > compatible extension of /usr/bin/byacc the only difference being
> > that it additionally supports
> >   | -B   create a backtracking parser

> I've made some effort to keep
> the two compatible, but sooner or later will get some bug report related
> to their differences.  Debian's the usual place for that sort of thing.
[...]
> ...with these caveats:

>   a) because of the backtracking support, the skeletons differ.

>   b) backtracking can be slow

> However, Mageia and OpenSUSE provide packages for byacc with backtracking
> enabled.
[...]

Hello Thomas,

afaict from
https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec
Fedora also builds without backtracking:
| # Revert default stack size back to 1
| # https://bugzilla.redhat.com/show_bug.cgi?id=743343
| find . -type f -name \*.c -print0 |
|   xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g'
| 
| %build
| %configure --disable-dependency-tracking
| %make_build

I would think that is something you need to solve upstream. It cannot be
a good thing(TM) if the same version of byacc is incompatible between
different major distributions. Don't you agree?

With "solve" meaning, that you decide whether you intend to provide a
limited-feature-set binary forever, and starting from there decide on
the naming of old (if it shall exist) and new byacc. 

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Andreas Metzler]

On 2022-01-15 Thomas Dickey  wrote:
[...]
> I am looking for a sponsor for my package "byacc":

>  * Package name: byacc
>Version : 1:2.0.20220114-1
>Upstream Author :  (Thomas E. Dickey)
>  * URL : https://invisible-island.net/byacc/
>  * License : GPL-3, public-domain, other-BSD
>  * Vcs : https://salsa.debian.org/debian/byacc
>Section : devel

> It builds those binary packages:

>   byacc - public domain Berkeley LALR Yacc parser generator
>   byacc2 - public domain Berkeley LALR Yacc parser generator, with 
> back-tracking
[...]

Hello Thomas,

I would like to question the introduction of another binary package:
* "byacc2" seems to be a (newly introduced) Debiansm. Googling for
  "byacc2" only finds links related to this RFS.
* The packages are tiny (about 100k) and have no conflicting files.
  /usr/bin/byacc2 and /usr/bin/byacc could be shipped in on binary
  package.
* Is the double compilation/binary necessary? - Is /usr/bin/byacc2
  incompatible with /usr/bin/byacc2? A quick glance at the yacc.1 seems
  to suggests that /usr/bin/byacc2 is a backward compatible extension of
  /usr/bin/byacc the only difference being that it additionally supports
  | -B   create a backtracking parser

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-11-06 Hugh McMaster  wrote:
[...]
> Sorry for the long delay. Real life got in the way.

Hello Hugh,

no worries.

> I’ve adapted your patch and made some other changes.
[...]

Thanks for doublechecking, uploaded.

cu Andreas



signature.asc
Description: PGP signature

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-10-15 Hugh McMaster  wrote:
[...]
> I spoke with the Debian QA Team and they were reluctant to remove gtkam
> because of popcon numbers.

> Myon said I should file a Serious bug against the package (#972085).

> Options for libexif-gtk seem to be reverting to GTK2 only, or building GTK2
> and GTK3 packages. I’m not entirely sure how that would work for the -dev
> package, although I could create a new -dev package for GTK3, I suppose.

Hello,

afaict the build against GTK2 and GTK3 produes identical header files,
only the library differ. So a combined dev package is possible.

Draft atached.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
>From 9c8f11e6e575d46d462d3f48237bd681dee5e76e Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Sun, 18 Oct 2020 14:14:45 +0200
Subject: [PATCH] Build both against GTK 2.0 and 3 to allow rdep(s) to migrate.

---
 debian/changelog   |  4 +++
 debian/control | 18 -
 debian/libexif-gtk-dev.install |  2 +-
 debian/libexif-gtk3-5.install  |  2 +-
 debian/libexif-gtk5.install|  2 ++
 debian/libexif-gtk5.symbols| 49 ++
 debian/rules   | 23 +---
 7 files changed, 93 insertions(+), 7 deletions(-)
 create mode 100644 debian/libexif-gtk5.install
 create mode 100644 debian/libexif-gtk5.symbols

diff --git a/debian/changelog b/debian/changelog
index c055c07..fbd1eb0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 libexif-gtk (0.5.0-1) experimental; urgency=medium
 
+  [ Hugh McMaster ]
   * New upstream version:
 - Fix cross-compilation with pkg-config (Closes: #911108).
   * Switch to GTK 3 (Closes: #967573).
@@ -41,6 +42,9 @@ libexif-gtk (0.5.0-1) experimental; urgency=medium
   * Add debian/not-installed file.
   * Add debian/upstream/metadata file.
 
+  [ Andreas Metzler ]
+  * Build both against GTK 2.0 and 3 to allow rdep(s) to migrate.
+
  -- Hugh McMaster   Thu, 01 Oct 2020 22:31:22 +1000
 
 libexif-gtk (0.4.0-2) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 8f19464..04d001c 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Uploaders: Hugh McMaster 
 Build-Depends:
  debhelper-compat (= 13),
  libexif-dev (>= 0.6.21),
+ libgtk2.0-dev,
  libgtk-3-dev,
  pkg-config,
 Standards-Version: 4.5.0
@@ -14,6 +15,19 @@ Homepage: https://libexif.github.io/
 Vcs-Browser: https://salsa.debian.org/debian-phototools-team/libexif-gtk
 Vcs-Git: https://salsa.debian.org/debian-phototools-team/libexif-gtk.git
 
+Package: libexif-gtk5
+Architecture: any
+Multi-Arch: same
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Library providing GTK+ 2.0 widgets to display/edit EXIF tags
+ Most digital cameras produce EXIF files, which are JPEG files with
+ extra tags that contain information about the image. The EXIF library
+ allows you to parse an EXIF file and read the data from those tags.
+ .
+ This library provides GTK+ widgets to display/edit EXIF tags.
+ .
+ This is the legacy version, built against GTK+ 2.0.
+
 Package: libexif-gtk3-5
 Architecture: any
 Multi-Arch: same
@@ -29,7 +43,9 @@ Package: libexif-gtk-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libexif-gtk3-5 (= ${binary:Version}), libexif-dev, libgtk-3-dev, ${misc:Depends}
+Depends: libexif-gtk5 (= ${binary:Version}),
+ libexif-gtk3-5 (= ${binary:Version}),
+ libexif-dev, libgtk2.0-dev, libgtk-3-dev, ${misc:Depends}
 Description: Library providing GTK+ widgets to display/edit EXIF tags (development files)
  Most digital cameras produce EXIF files, which are JPEG files with
  extra tags that contain information about the image. The EXIF library
diff --git a/debian/libexif-gtk-dev.install b/debian/libexif-gtk-dev.install
index 603b965..75314e4 100644
--- a/debian/libexif-gtk-dev.install
+++ b/debian/libexif-gtk-dev.install
@@ -1,4 +1,4 @@
 usr/include/libexif-gtk/*
 usr/lib/*/lib*.a
 usr/lib/*/lib*.so
-usr/lib/*/pkgconfig/libexif-gtk3.pc
+usr/lib/*/pkgconfig/libexif-gtk*.pc
diff --git a/debian/libexif-gtk3-5.install b/debian/libexif-gtk3-5.install
index e53df30..94d9c0a 100644
--- a/debian/libexif-gtk3-5.install
+++ b/debian/libexif-gtk3-5.install
@@ -1,2 +1,2 @@
-usr/share/locale
+usr/share/locale/*/*/libexif-gtk3-5.*
 usr/lib/*/libexif-gtk3.so.*
diff --git a/debian/libexif-gtk5.install b/debian/libexif-gtk5.install
new file mode 100644
index 000..fb2081f
--- /dev/null
+++ b/debian/libexif-gtk5.install
@@ -0,0 +1,2 @@
+usr/share/locale/*/*/libexif-gtk-5.*
+usr/lib/*/libexif-gtk.so.*
diff --git a/debian/libexif-gtk5.symbols b/debian/libexif-gtk5.symbols
new file mode 100644
index 000..f5a4562
--- /dev/null
+++ b/debian/libexif-gtk5.symbols
@@ -0,0 +1,49 @@
+libexif-gtk.so.5 libexif-gtk5 #MINVER#
+* Build-Depends-Package: libexif-gtk-dev
+ gtk_exif_browser_get_type@Base

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-10-04 Hugh McMaster  wrote:
[...]
> We can't remove libexif-gtk, as libexif-gtk-dev is a r-b-dep of mlt.

I missed that one.

> Interestingly, mlt doesn't use GTK2, just the libexif functionality.
[...]

Afaict it is an unused b-d, bug filed.

cu Andreas

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-10-01 Hugh McMaster  wrote:
[...]
> I've uploaded a new version of libexif-gtk to Debian Mentors, fixing
> the issues discussed in this thread.

> Thanks for your help with this.

Good morning Hugh,

I think this looks alright now.

I thought I should try it out and there is a only single reverse
dependency, gtkam. Afaict gtkam is orphaned and dead upstream (last commit
2016) and does not work with GTK 3. :-(

So I am wondering whether it would not be better for Debian to drop both
libexif-gtk and gtkam instead of of ading to the workload of ftpmaster
by uploading a new version of libexif-gtk.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-09-30 Hugh McMaster  wrote:
> Hi Andreas,

> On Tue, 29 Sep 2020 at 22:03, Andreas Metzler wrote:
[...]
> > The transitional package makes no sense, it actually causes breakage.

> > Packages depend on libexif-gtk5 because they need a library with
> > soname libexif-gtk.so.5. The dummy package makes libexif-gtk5 0.5.0-1
> > + libexif-gtk3-5 fulfill this dependency without
> > providing libexif-gtk.so.5. Any package depending on libexif-gtk5 will need
> > to be rebuilt against libexif-gtk-dev 0.5 and will then depend
> > on libexif-gtk3-5.
> >

> Just so I understand, do we need the dummy package? I thought we did, to
> allow upgrades to work correctly.

Hello Hugh,

yes you do understand correctly, a dummy does not make sense here.
Runtime library are generally installed as a dependency, when the
depending package is rebuilt against the newer library apt will pull it
in and the old library can be autoremoved.

> I’m also targeting experimental to be safe, as I expected some breakage
> from this change.
[...]

Also library transition will need to be coordinated with Debian release,
pre-upload to sid.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#971067: RFS: libexif-gtk/0.5.0-1

[Andreas Metzler]

On 2020-09-27 Hugh McMaster  wrote:
[...]
> I am looking for a sponsor to upload the package "libexif-gtk" to NEW,
> as switching to GTK 3 caused the main package to be renamed.

>  * Package name: libexif-gtk
[...]
> The source builds the following binary packages:

>   libexif-gtk-dev - Library providing GTK+ widgets to display/edit
> EXIF tags (development files)
>   libexif-gtk5 - Library providing GTK+ widgets to display/edit EXIF
> tags (transitional package)
>   libexif-gtk3-5 - Library providing GTK+ widgets to display/edit EXIF tags
[...]


Hello Hugh,

I have just taken a quick look:

[nitpick] Explicit b-dep on autopoint is superfluous, debhelper pulls it
in for dh_autoreconf.

The transitional package makes no sense, it actually causes breakage.
Packages depend on libexif-gtk5 because they need a library with soname
libexif-gtk.so.5. The dummy package makes libexif-gtk5 0.5.0-1 +
libexif-gtk3-5 fulfill this dependency without providing
libexif-gtk.so.5. Any package depending on libexif-gtk5 will need to be
rebuilt against libexif-gtk-dev 0.5 and will then depend on
libexif-gtk3-5.

Also libexif-gtk5 0.4 and libexif-gtk3-5 should be co-installable (no
breaks/replaces - policy 8.1, worth reading in whole), afaict this
should be easily possible once the gettext message catalogues names are
versioned. I /think/ (untested!) this should do the trick:

--- libexif-gtk-0.5.0.orig/configure.ac
+++ libexif-gtk-0.5.0/configure.ac
@@ -47,7 +47,7 @@ dnl GP_CONFIG_MSG([Features])
 # ---
 ALL_LINGUAS="de es fr pl ru"
 AM_PO_SUBDIRS
-GP_GETTEXT_HACK([${PACKAGE}-${LIBEXIF_GTK_CURRENT}],
+GP_GETTEXT_HACK([${PACKAGE}3-${LIBEXIF_GTK_CURRENT}],

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#960691: RFS: libexif/0.6.21-7 -- library to parse EXIF files

[Andreas Metzler]

On 2020-05-15 Hugh McMaster  wrote:
> Package: sponsorship-requests
> Severity: normal

> Dear mentors and Debian PhotoTools Team members,

> I am looking for a sponsor for the package "libexif"

>  * Package name: libexif
>Version : 0.6.21-7
[..]

Will do.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Re: Lintian - pkg-config-references-unknown-shared-library

[Andreas Metzler]

On 2019-02-15 Herbert Fortes  wrote:
> I working on a Debian revison for libgphoto2 and
> have this Lintian about pkg-config.

> pkg-config-references-unknown-shared-library

> The libgphoto2_port/libgphoto2_port.pc.in file has:

> Libs: -L${libdir} -lgphoto2 -lm
[...]

Hello,
Looks like a false positive, lintian warns about -lm, the full error is:
W: libgphoto2-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libgphoto2.pc -lm (line 14)
W: libgphoto2-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libgphoto2_port.pc -lm (line 12)

libm.so is shipped in libc6-dev. How about a bugreport?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#897102: libexif-gtk/0.4.0-2

[Andreas Metzler]

On 2018-05-01 Hugh McMaster  wrote:
> Hi Andreas,

> I've updated d/copyright and d/changelog with reference to your feedback.
[...]

Hello Hugh,

the correspondig change for 
Use 'uversionmangle' instead of 'oversionmangle'.
seems to have been lost. Also all license statements have a "or later
clause" and afaik should use "+" in the short name ("LGPL-2.1+").

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
>From 906ebb93e97ee71883cc265bab268597d10c35d9 Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Tue, 1 May 2018 13:42:09 +0200
Subject: [PATCH 1/2] Add lost change:

Use 'uversionmangle' instead of 'oversionmangle'.
---
 debian/watch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/watch b/debian/watch
index 3e90080..eee700e 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=4
-opts="oversionmangle=s/_/\./g" \
+opts="uversionmangle=s/_/\./g" \
   https://github.com/libexif/libexif-gtk/tags .*\/libexif-gtk-(\d\S+)-release\.tar\.gz
-- 
2.17.0

>From 13644f58474a9a341682ba52891e931c26af28f1 Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Tue, 1 May 2018 14:03:11 +0200
Subject: [PATCH 2/2] Fix license shortname

---
 debian/copyright | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 43399a5..408d95a 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,60 +2,60 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: libexif-gtk
 Upstream-Contact: Lutz Müller 
 Source: https://libexif.github.io/
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: *
 Copyright: 2001-2004 Lutz Müller 
2002 Hans Ulrich Niedermann 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: gtk-extensions/*
 Copyright: 2001 Lutz Müller 
-License: LGPL-2
+License: LGPL-2+
 
 Files: libexif-gtk/*
 Copyright: 2001-2002 Lutz Müller 
-License: LGPL-2
+License: LGPL-2+
 
 Files: libexif-gtk/gtk-exif-entry-version.c
 Copyright: 2001-2002 Lutz Müller 
2002 Arnaud Rouanet 
-License: LGPL-2
+License: LGPL-2+
 
-Files: libexif-gtk/gtk-exif-util.h
+Files: libexif-gtk/gtk-exif-util.h tests/test-libexif-gtk.c
 Copyright: 2002 Lutz Müller 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: m4m/gp-byteorder.m4 m4m/stdint.m4
 Copyright: 2001-2002 Dan Fandrich 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: po/de.po
 Copyright: 2002 Lutz Müller 
2004-2010 Marcus Meissner 
2009 Chris Leick 
2012 Dan Fandrich 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: po/es.po
 Copyright: 2002-2004 Fabian Mandelbaum 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: po/fr.po
 Copyright: 2003-2004 Arnaud Launay 
2011 Emmanuel Bouthenot 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: po/pl.po
 Copyright: 2005-2013 Jakub Bogusz 
-License: LGPL-2.1
+License: LGPL-2.1+
 
 Files: po/ru.po
 Copyright: 2003-2004 Vyachelav Dikonov 
2006 Alexandre Prokoudine 
-License: LGPL-2.1
+License: LGPL-2.1+
 
-License: LGPL-2.1
+License: LGPL-2.1+
  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
@@ -73,7 +73,7 @@ License: LGPL-2.1
  On Debian systems, the complete text of the GNU Lesser General Public License
  version 2.1 can be found in `/usr/share/common-licenses/LGPL-2.1'.
 
-License: LGPL-2
+License: LGPL-2+
  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU Library General Public
  License as published by the Free Software Foundation; either
@@ -96,9 +96,9 @@ Copyright: 2002-2004 Christophe Barbe 
2004-2005 Frederic Peters 
2009-2011 Emmanuel Bouthenot 
2018 Hugh McMaster 
-License: GPL-2
+License: GPL-2+
 
-License: GPL-2
+License: GPL-2+
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
-- 
2.17.0

Bug#897102: libexif-gtk/0.4.0-2

[Andreas Metzler]

On 2018-04-29 Hugh McMaster  wrote:
> On Sunday, 29 April 2018 10:11 PM, Andreas Metzler wrote:
[...]
> > 0.4.0-1 says "Switch to LGPL-2.1+ for libexif-gtk 0.4.0.". Is this
> > correct? While COPYING contains a copy of LGPL-2.1 only a single c/h
> > file (gtk-exif-util.h) has this license in its copyright header.

> The po files and tests/test-libexif-gtk.c are also licensed under
> LGPL-2.1.  I see your point, though. The other files are LGPL-2.
> However, all of those files have "either version 2 of the License, or
> (at your option) any later version" written in them, which would be
> okay.

> Having said that, it may be better to fix d/copyright to account for the
> mixed LGPL-2/2.1 files. What do you think? It's no problem for me to do.

That would be great. TIA.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#897102: libexif-gtk/0.4.0-2

[Andreas Metzler]

On 2018-04-29 Hugh McMaster  wrote:
> Package: sponsorship-requests
> Severity: normal

> Dear mentors and Debian PhotoTools Team,

> I am looking for a sponsor for a Team Upload of the package "libexif-gtk".

> Version 0.4.0-1 is is currently in Experimental and is ready to move into 
> Unstable.
[...]
> Changes since the last upload:
[...]
>   * Depend on libpango-1.0-0 instead of the transitional package
> libpango1.0-0 (Closes: #865170).
[...]

Nitpick (nice to have, no reason for a new upload on its own):
This changelog entry threw me, I was searching in vain for a related
source change.  "Rebuild against newer newer pango fixes dependency on
transitional package  (Closes: #865170)." would be a better.

0.4.0-1 says "Switch to LGPL-2.1+ for libexif-gtk 0.4.0.". Is this
correct? While COPYING contains a copy of LGPL-2.1 only a single c/h
file (gtk-exif-util.h) has this license in its copyright header.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#894615: RFS: libexif/0.6.21-5

[Andreas Metzler]

On 2018-04-02 Hugh McMaster  wrote:
> Package: sponsorship-requests
> Severity: normal

> Dear mentors and Debian PhotoTools Team,

> I am looking for a sponsor for a Team Upload of the package "libexif".
[...]

Hello Hugh,

looks good except for the watchfile, you need uversionmangle
instead of oversionmangle.

Also I have searched in vain for your gnupg key, is it aailable
somewhere?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Disable building of a specific binary package on selected archs

[Andreas Metzler]

Hello,

I would like to disable building of libelua-bin and libelua1 binary
package on amd64. [1] However negated architecture specifiers [!amd64]
are not allowed in the Architecture field of debian/control. As a hotfix
I can explicitely list all archs present in unstable/experimental.

Is there a clean way to do this?

The only thing I have come up with is creating control from control.in
at source package generation time, using something like
dpkg-architecture -L | grep -v arm64
as architecture list.

cu Andreas
[1] https://phab.enlightenment.org/T6156

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Problem with dh_installman: usr/share/man/man8/amadmin.8: No such file or directory at /usr/bin/dh_installman line 131.

[Andreas Metzler]

Jose M Calhariz  wrote:
> I am changing the rules of the package amanda to debhelper 9 and I am
> stopped in a problem with dh_installman.  I have checked what I know
> and everything is correct.  But still I think that is something
> obvious that I am missing.  Possibly the manpages have an error in
> nroff code.

> The tail of the debuild is:

>dh_installman
> install -d debian/amanda-server/usr/share/man/man1/
> install -p -m0644 debian/activate-devpay.1 
> debian/amanda-server/usr/share/man/man1/activate-devpay.1
> usr/share/man/man8/amadmin.8: No such file or directory at 
> /usr/bin/dh_installman line 131.
[...]
> https://anonscm.debian.org/git/collab-maint/amanda.git
[...]

Hello,

(sid)ametzler@argenau:/tmp/FLANN/amanda-3.3.9$ find -name amadmin.8
./man/amadmin.8
./debian/tmp/usr/share/man/man8/amadmin.8

If you want to install this manpage with dh_installman you'll need to
list
debian/tmp/usr/share/man/man8/amadmin.8
instead of
usr/share/man/man8/amadmin.8
in debian/amanda-server.manpages. 

dh_installman does not search below debian/tmp as dh_install does. In
my personal experience it is mainly useful for manpages which are not
installed by "make install", e.g. Debian provided manpages in debian/.
I would suggest to install manpages which are handled by "make
install" with dh_install instead.

BTW I think you are missing
--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,7 @@ confflags = --prefix=/usr \
--enable-s3-device

 %:
-   dh $@ --parallel
+   dh $@ --with autoreconf --parallel

 override_dh_auto_configure:
dh_auto_configure -- $(confflags)

hth, cu Andreas


-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: debian/watch - check multiple hosts?

[Andreas Metzler]

Paul Wise  wrote:
> On Tue, Dec 29, 2015 at 3:24 PM, Andreas Metzler wrote:

>> is it possible to have uscan check multiple hosts? e.g.
>> for GNU findutils I would like to look at both stable and unstable
>> releases i.e. combining these two watchfiles:

> uscan already supports this, add two sites in one watch file:
> version=3
[...]

Perfect, thank you.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: debian/watch - check multiple hosts?

[Andreas Metzler]

Ben Finney  wrote:
> Andreas Metzler  writes:

>> is it possible to have uscan check multiple hosts? e.g. for GNU
>> findutils I would like to look at both stable and unstable releases

> Are you aware the watch file is meant to find a *single* tarball?

Yes, I am aware of that.

> What would you want the result of scanning multiple hosts; how would
> you want differences resolved to a single tarball, at a single version?

I do not see a huge conceptual difference to scanning a single host.
uscan looks at a list of locations for files matching a specific
pattern, with a subpattern for the version number. uscan simply grabs
the file with the highest version number. Even now uscan will
often find multiple files with the same version number (gz|bz2|xz) and
has to choose one.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

debian/watch - check multiple hosts?

[Andreas Metzler]

Hello,

is it possible to have uscan check multiple hosts? e.g.
for GNU findutils I would like to look at both stable and unstable
releases i.e. combining these two watchfiles:

version=3
opts=pgpsigurlmangle=s/$/.sig/ \
ftp://alpha.gnu.org/gnu/findutils/findutils-([\d\.\d]+)\.tar\.(?:gz|bz2|xz)

version=3
opts=pgpsigurlmangle=s/$/.sig/ \
ftp://ftp.gnu.org/gnu/findutils/findutils-([\d\.\d]+)\.tar\.(?:gz|bz2|xz)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Depends on exact version

[Andreas Metzler]

Daniel Lintott  wrote:
> On Sun, Nov 16, 2014 at 02:39:15PM +0100, Andreas Metzler wrote:
>> Daniel Lintott  wrote:
>>> I have a package which is split into two sources (a server and
>>> gui). The server version should match the gui version (upstream
>>> version) at all times.
[...]
> The metapackage is needed to provide an upgrade route from the GNS3
> 0.8.x [1] to the new GNS3 1.x which is split into a gui/server.
> Obviouosly it's preferred for existing users of GNS3 to upgrade to
> the new version, as the old version (what will become gns3-legacy)
> is no longer in active development.
[...]

Hello,

I see. I do not understand, though, why you need something more
strict/complicated than a simple
-
Package: metapackage
Architecture: all
Depends: server (>= ${binary:Version}, client (>= ${binary:Version})
-

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lgo5kb-gcj@argenau.downhill.at.eu.org

Re: Depends on exact version

[Andreas Metzler]

Daniel Lintott  wrote:
> I have a package which is split into two sources (a server and gui). The
> server version should match the gui version (upstream version) at all times.

> Because of this when I'm creating the meta-package that will depend on
> both the gui and server, should be versioned to to be the same upstream
> version.
[...]

Hello,

can you add a little bit more info? Are server and GUI running
on the same machine? If they are, there is no need for the
metapackage, the GUI package can simply depend on the server. OTOH if
they can run (and usualy do run) on different machines a meta-package
that syncs server and gui on a single machine would not help.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/11mmjb-9vl@argenau.downhill.at.eu.org

Bug#759742: RFS: tkinfo/2.8-5 [ITA, RC]

[Andreas Metzler]

On 2014-08-29 Peter  wrote:
[...]
>   I am looking for a sponsor for my package "tkinfo"

Hello Peter,
thanks for adopting this package, I occasionally use it and will be
happy to sponsor.

[...]
>   Changes since the last upload:
[...]
>* Add dh-installmime to binary-indep (Closes: #723710)

Just adding dh-installmime without shipping a mime file does not
change the binary package and therefore does not fix this whishlist
request.

debian/copyright is missing an entry for debian/*. Could you ask Craig
whether he was simply using the same license as upstream?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140913115752.gc28...@downhill.g.la

Request for review - python-gnutls

[Andreas Metzler]

Hello,

given that python-gnutls is one of the last packages still depending
on libgnutls26 [1] I have thrown in a little bit of effort to prepare a
NMU fixing this.

However I am not a regular python user and would therefore appreciate
a second set of eyes doublechecking that the result is not more broken
than the version currently in sid.

https://people.debian.org/~ametzler/python-gnutls_2.0.1-0.1.dsc

Thanks in advance,
cu Andreas
[1] https://bugs.debian.org/736525
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140906113920.ga3...@downhill.g.la

Re: Bug#740482: RFS: [RC][security] imagemagick/8:6.7.7.10-8

[Andreas Metzler]

On 2014-03-02 Bastien ROUCARIES  wrote:
> Le 2 mars 2014 16:19, "Andreas Metzler"  a écrit :
>> On 2014-03-02 Bastien ROUCARIES  wrote:
>>>   I am looking for a sponsor for my package "imagemagick"
[...]
>> Uploaded.

> Rejected by ftpmaster* reuploaded repacked on mentor.
[...]


Hello Bastien,

I have just uploaded. FWIW I appreciate that you made a minimal
changes upload to faciliate quick checking.

Regarding your other mail:
> I am preparing the stable-security package (i am pbuilding it). Could
> you also sponsor it?

I will happily do the sponsoring if debian-security think this
should be solved through a stable update instead of a DSA. Have you
already doubleckecked with -release?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140303185255.ga5...@downhill.g.la

Re: Bug#740482: RFS: [RC][security] imagemagick/8:6.7.7.10-8

[Andreas Metzler]

On 2014-03-02 Bastien ROUCARIES  wrote:
> Package: sponsorship-requests
> Severity: normal [important for RC bugs, wishlist for new packages]

>   Dear mentors,

>   I am looking for a sponsor for my package "imagemagick"
[...]
>   Changes since the last upload:
> Fix three security bug

Uploaded.

On a sidenote, you key has expired 2013-12-20. Could you please bump
the expiry date of your pgp key and upload it?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: Digital signature

Re: Is there a place for ndjbdns in Debian

[Andreas Metzler]

Dariusz Dwornikowski  wrote:
> I am working on a MaraDNS package, the upstream Author, Sam Trenholme
> suggested that maybe it could also worth packaging ndjbdns, a djbdns
> fork but with GPL licence and all bugs fixed. Also the upstream of
> ndjbdns is quite responsive and active. 
[...]

Hello,

from a users point of view I would love to see a tiny performing DNS
cache in Debian which is maintained upstream. However judging from the
respective descriptions on the web I guess that deadwood should work
as well as a djbdns fork.

OTOH I wonder what would keep you as maintainer interested in taking
care of two different packages doing basically the same job. You will
soon find out that you like one better and will only use this one. You
might then have a hard time motivating yourself to invest time in the
other one.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/88vhta-6vb@argenau.downhill.at.eu.org

Re: dh: different dh option for -indep

[Andreas Metzler]

Raphael Hertzog  wrote:
> On Mon, 30 Dec 2013, Andreas Metzler wrote:
[...]
>> MYDHMODS := $(shell if dh_listpackages | grep -q foo-doc ; \
>> then echo "--with autoreconf,sphinxdoc" ; \
>> else echo "--with autoreconf" ; fi)
[...]
> Nice trick! Still, this is a wrong optimization IMO. This complexifies the
> packaging for no important gain.

> It could be different if the package was one of those required to
> bootstrap a new architecture but for a random package, it's just easier
> and more maintainable to keep the sphinxdoc build-dep in Build-Depends.

Hello,

you might be right. I was shown the trick at Debconf, and used it for
breaking a gnutls bootstrap cycle.

If all you have is a hammer, everything looks like a nail. ;-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/e14bpa-i53@argenau.downhill.at.eu.org

Re: dh: different dh option for -indep

[Andreas Metzler]

Olе Streicher  wrote:
> 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:
[...]

Hello,
Assuming foo-doc is arch independent and therefore not built on -B this
should work: 

MYDHMODS := $(shell if dh_listpackages | grep -q foo-doc ; \
then echo "--with autoreconf,sphinxdoc" ; \
else echo "--with autoreconf" ; fi)

%:
dh  $@ $(MYDHMODS)

hth, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/70p8pa-i16@argenau.downhill.at.eu.org

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

[Andreas Metzler]

Olе Streicher  wrote:
> 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).

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.

> 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. Another option would be to
move out the documentation to a separate arch-independent package.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/u766pa-9ao@argenau.downhill.at.eu.org

Re: Different symbols for different architectures

[Andreas Metzler]

Paul Wise  wrote:
> On Sun, Dec 29, 2013 at 5:24 PM, Mattia Rizzolo wrote:
>> Seems that different architectures have different symbols.

> To me it doesn't look that simple, since the missing symbols are the
> same on many arches. It seems like upstream is basing the
> presence/absence of some public functions on what is returned by
> ./configure. For example rpl_strstr:
[...]
> If rpl_* means replacement for broken functions (I guess it does), it
> may even be leaking symbols that are meant to be private, which should
> definitely be fixed.

Something like

--- licenseutils-0.0.7.orig/src/Makefile.am
+++ licenseutils-0.0.7/src/Makefile.am
@@ -29,7 +29,7 @@ liblicenseutils_la_SOURCES=licensing.c g
 include styles.am

 liblicenseutils_la_LIBADD = @LIBINTL@ $(top_builddir)/lib/libgnu.la 
$(GLIB_LIBS) $(LIBPNG_LIBS)
-liblicenseutils_la_LDFLAGS = -version-info 0:0:0 -export-dynamic -no-undefined
+liblicenseutils_la_LDFLAGS = -version-info 0:0:0 -export-dynamic -no-undefined 
-export-symbols-regex '^lu_.*'

would help.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/blj5pa-07d@argenau.downhill.at.eu.org

Re: Correcting a version number

[Andreas Metzler]

Daniel Lintott  wrote:
> On 10/12/13 19:21, Dominik George wrote:
>>> [2] http://qa.debian.org/cgi-bin/watch?pkg=vpcs_0.5b0-1

>> In that special case, I'd even say your versioning "mistake" is
>> good because upstream's ~ notation is a mess. That char is reserved
>> for Debian ;) (yes, that's false and not so humble ;))!
[...]
> The output from the above seems a little confusing (to me) as upstream
> don't use ~ which can be seen in the upstream-url, as well as on the
> upstream sf page [1]

> It's entirely possible that there is also a mistake in the watch
> file... which wouldn't help matters.

Hello,
The watchfile looks perfectly fine:

version=3
opts=uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|BETA|beta|alpha|b|a)[\-\.]?\d*)$/$1~$2/
 \
http://qa.debian.org/watch/sf.php/vpcs/vpcs-(\d.*)-(?:src|source)\.(?:tgz|tbz|tbz2|txz|tar\.(?:gz|bz2|xz))

It looks at the upstream version, sees "0.5b0" and mangles it into a
version number that sorts properly in debian, "0.5~b0".

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/lqnmna-tk3@argenau.downhill.at.eu.org

Re: Correcting a version number

[Andreas Metzler]

Daniel Lintott  wrote:
[..]
> I have realised that in an earlier package upload, I made a blunder
> with regards the version of the package.

> The package was versioned as 0.5b0-1, though I somehow missed, despite
> testing the watch file that this should have been 0.5~b0-1.

> I have seen some discussion on correcting the version number, either
> by using an epoch or by adding an additional part to the version number.

> - From what I can see, the only way to fix the version number here is to
> use an epoch, but from what I've this should be avoided if possible,
> so does anyone have any other suggestion on how to correct this
> version number?
[...]

Hello,

I do not think there are any other reasonable[1] possibilities
available. You can either use an epoch (forever) or live with a ugly
version number for some time.

Personally I would use an ugly version number for the 0.5 release:

Upstream   Debian
0.5b0  0.5b0-1
0.5b1  0.5b1-1
...
0.5rc1 0.5rc1-1
...
0.50.5+rel-1
0.6b0  0.6~b1

(Please doublcheck the sorting with dpkg --compare-versions, I might
have made an error, too. ;-)

hth, cu Andreas

[1] renaming the package does not count.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/rt3kna-hp4@argenau.downhill.at.eu.org

Bug#726873: RFS: id3/0.15-4

[Andreas Metzler]

On 2013-10-20 Stefan Ott  wrote:
> Package: sponsorship-requests
> Severity: normal

> Dear mentors,

> I am looking for a sponsor for my package "id3"
[...]

Hello,

I have just uploaded the package.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/20131020132943.ga3...@downhill.g.la

Re: Versionned dependancies on build-essential packages. (was: Re: Where did Bacula 1.38.11-7+b1 come from?)

[Andreas Metzler]

On 2007-02-24 Charles Plessy <[EMAIL PROTECTED]> wrote:
> Le Fri, Feb 23, 2007 at 07:30:38PM +0100, Andreas Metzler a écrit :
> > Build-Depends: dpkg-dev (>=1.13.19)
[...]
> [Thread from -devel diverted to -mentors.]

I do not follow that list, thanks for the cc.

> I was just wondering the reason why the build-dependancy on dpkg-dev is
> necessary. Dpkg-dev is build-essential and is > 1.13.19 in unstable and
> testing anyway. Couldn't this be safely omitted when uploading for
> unstable ?

It is indeed not necessary for unstable, but it makes a backporter's
work more easy.
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RF{S,C}: gtklp 1.0rel+1.0d

[Andreas Metzler]

On 2005-06-14 "Zak B. Elep" <[EMAIL PROTECTED]> wrote:
> [Cc'ing Andreas Metzler as he was my last sponsor ;)]

> Hi!  I've repackaged gtklp to accomodate the new version 1.0d.  There
> are no bugfixes in this package :( but I've done some changes to
> debian/rules and /control for proper handling of config.{guess,sub} files.
[...]

Hello,
sponsored, as I happen to be temporarily in a place with more bandwith.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


signature.asc
Description: Digital signature

Re: Packaging xmountains...

[Andreas Metzler]

On 2004-09-11 MiguelGea <[EMAIL PROTECTED]> wrote:
> On ds, 2004-09-11 at 00:12, Thomas Viehmann wrote:
> > MiguelGea wrote:
> > > install in /usr/share/man/man* but no in usr/X11R6/man/man1
 
> > Why would you (Policy 12.1)?
> If I execute lintian -i xmountains it say to me this:

> E: xmountains: manpage-for-x11-binary-in-wrong-directory 
> usr/X11R6/bin/xmountains usr/share/man/man1/xmountains.1.gz
> N:
> N:   Manual pages for binaries which are located in /usr/X11R6/bin
> should
> N:   be installed below /usr/X11R6/man.
> N:
> N:   Note that normally only packages that are part of X itself and
> those
> N:   that are using some arcane Imakefiles should actually install
> binaries
> N:   into /usr/X11R6/bin.
> N:

> but in Policy 12.1 it says:

> You should install manual pages in nroff source form, in appropriate places 
> under /usr/share/man. You should only use sections 1 to 9 (see the FHS for 
> more details).
>  You must not install a preformatted "cat page".

> Is this a bug in lintian?

No, lintian is entirely correct. However why do install
the binary in usr/X11R6/bin/? Is it using xmkmf? 
   cu andreas

Re: Packaging xmountains...

[Andreas Metzler]

On 2004-09-11 MiguelGea <[EMAIL PROTECTED]> wrote:
> On ds, 2004-09-11 at 00:12, Thomas Viehmann wrote:
> > MiguelGea wrote:
> > > install in /usr/share/man/man* but no in usr/X11R6/man/man1
 
> > Why would you (Policy 12.1)?
> If I execute lintian -i xmountains it say to me this:

> E: xmountains: manpage-for-x11-binary-in-wrong-directory usr/X11R6/bin/xmountains 
> usr/share/man/man1/xmountains.1.gz
> N:
> N:   Manual pages for binaries which are located in /usr/X11R6/bin
> should
> N:   be installed below /usr/X11R6/man.
> N:
> N:   Note that normally only packages that are part of X itself and
> those
> N:   that are using some arcane Imakefiles should actually install
> binaries
> N:   into /usr/X11R6/bin.
> N:

> but in Policy 12.1 it says:

> You should install manual pages in nroff source form, in appropriate places 
> under /usr/share/man. You should only use sections 1 to 9 (see the FHS for more 
> details).
>  You must not install a preformatted "cat page".

> Is this a bug in lintian?

No, lintian is entirely correct. However why do install
the binary in usr/X11R6/bin/? Is it using xmkmf? 
   cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bashisms and Dashisms...

[Andreas Metzler]

On Mon, Sep 06, 2004 at 05:51:47PM +0200, Frank Küster wrote:
> Andreas Metzler <[EMAIL PROTECTED]> schrieb:
> > On Mon, Sep 06, 2004 at 04:18:21PM +0200, Frank Küster wrote:
> >> A maintainer script with a #!/bin/sh line should only use posix
> >> syntax. If one needs more features (e.g. test -L), one can instead use
> >> #!/bin/bash.

> > test -L is POSIX afaict.

> Hm, so how can *I* tell? I use to look at SUSV2 at
> http://www.opengroup.org/onlinepubs/007908799/

Susv2 is not POSIX afaik, I use 
http://www.opengroup.org/onlinepubs/009695399/mindex.html

http://www.opengroup.org/onlinepubs/009695399/utilities/test.html
   cu andreas

Re: Bashisms and Dashisms...

[Andreas Metzler]

On Mon, Sep 06, 2004 at 04:18:21PM +0200, Frank Küster wrote:
> A maintainer script with a #!/bin/sh line should only use posix
> syntax. If one needs more features (e.g. test -L), one can instead use
> #!/bin/bash.

test -L is POSIX afaict.

> However, this seems unnecessarily restricted to me. dash also knows
> the non-POSIX extensions to the test builtin. So if /bin/sh pointed to
> dash, my script would still run.
[...]

This issue has not yet been decided upon, but curently we do not take
it very strict, the current rule of the thumb is:

/bin/sh Script runs with | 
bashdashposh | bug-severity
-+
yes yes yes  | none
yes yes no   | minor
yes no  no   | serious

I guess we'll end up requiring posix + selected features for /bin/sh
(echo -n, command -v, ...)
cu andreas

Re: Bashisms and Dashisms...

[Andreas Metzler]

On Mon, Sep 06, 2004 at 05:51:47PM +0200, Frank Küster wrote:
> Andreas Metzler <[EMAIL PROTECTED]> schrieb:
> > On Mon, Sep 06, 2004 at 04:18:21PM +0200, Frank Küster wrote:
> >> A maintainer script with a #!/bin/sh line should only use posix
> >> syntax. If one needs more features (e.g. test -L), one can instead use
> >> #!/bin/bash.

> > test -L is POSIX afaict.

> Hm, so how can *I* tell? I use to look at SUSV2 at
> http://www.opengroup.org/onlinepubs/007908799/

Susv2 is not POSIX afaik, I use 
http://www.opengroup.org/onlinepubs/009695399/mindex.html

http://www.opengroup.org/onlinepubs/009695399/utilities/test.html
   cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bashisms and Dashisms...

[Andreas Metzler]

On Mon, Sep 06, 2004 at 04:18:21PM +0200, Frank Küster wrote:
> A maintainer script with a #!/bin/sh line should only use posix
> syntax. If one needs more features (e.g. test -L), one can instead use
> #!/bin/bash.

test -L is POSIX afaict.

> However, this seems unnecessarily restricted to me. dash also knows
> the non-POSIX extensions to the test builtin. So if /bin/sh pointed to
> dash, my script would still run.
[...]

This issue has not yet been decided upon, but curently we do not take
it very strict, the current rule of the thumb is:

/bin/sh Script runs with | 
bashdashposh | bug-severity
-+
yes yes yes  | none
yes yes no   | minor
yes no  no   | serious

I guess we'll end up requiring posix + selected features for /bin/sh
(echo -n, command -v, ...)
cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Andreas Metzler]

On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote:
[...]
> > Why do you call dpatch 'obfuscated' ? 
[...]
> Compared to simply making the source changes directly, it's obfuscated.

Agreed.

> It's also obfuscated for users who can no longer use 'dpkg-source -x'
> (as documented since the dawn of time) to see the source code from which
> programs are built; instead, they have to hunt through a maze of twisty
> makefiles in order to work out the correct debian/rules invocation to
> produce the patched source, which is different for almost every patch
> system used in Debian and is often poorly documented.

dpatch is actually documented quite well. (The packaged dbs also
features usable documentation.) Hell starts with the homegrown
patch-systems or cdbs.

> I recommend using a good revision control system instead, which offers
> similar benefits to developers while leaving things clear for users.

I disagree that this is so clear-cut. The still most popular system
CVS simply does not offer this functionality. e.g. you have two
distinct patchsets: patchset A fixing issue A touching files 1, 2,
and 3 and patchset B fixing issue B touching files 2, 3 and 4.

CVS simply does not offer the possibility to keep these patchsets
separate (except for checking in diff-files.) over several generations
of a file.

I doubt svn favours a lot better in this respect (otherwise why would
xfree-packaging still use a dpatch-like system?) Bitkeeper can do it,
and I guess arch, too.

If you are thinking "use separate .diff files in your repository but
upload a plain diff.gz with everything mangled together" I disagree.
I'd rather have slightly more complicated but usable sourcepackages in
the archive. (Think of maintainer goes MIA or NMU.)
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt

[Andreas Metzler]

On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote:
[...]
> > Why do you call dpatch 'obfuscated' ? 
[...]
> Compared to simply making the source changes directly, it's obfuscated.

Agreed.

> It's also obfuscated for users who can no longer use 'dpkg-source -x'
> (as documented since the dawn of time) to see the source code from which
> programs are built; instead, they have to hunt through a maze of twisty
> makefiles in order to work out the correct debian/rules invocation to
> produce the patched source, which is different for almost every patch
> system used in Debian and is often poorly documented.

dpatch is actually documented quite well. (The packaged dbs also
features usable documentation.) Hell starts with the homegrown
patch-systems or cdbs.

> I recommend using a good revision control system instead, which offers
> similar benefits to developers while leaving things clear for users.

I disagree that this is so clear-cut. The still most popular system
CVS simply does not offer this functionality. e.g. you have two
distinct patchsets: patchset A fixing issue A touching files 1, 2,
and 3 and patchset B fixing issue B touching files 2, 3 and 4.

CVS simply does not offer the possibility to keep these patchsets
separate (except for checking in diff-files.) over several generations
of a file.

I doubt svn favours a lot better in this respect (otherwise why would
xfree-packaging still use a dpatch-like system?) Bitkeeper can do it,
and I guess arch, too.

If you are thinking "use separate .diff files in your repository but
upload a plain diff.gz with everything mangled together" I disagree.
I'd rather have slightly more complicated but usable sourcepackages in
the archive. (Think of maintainer goes MIA or NMU.)
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

[Andreas Metzler]

On Mon, Aug 30, 2004 at 09:45:26AM -0700, Paul Telford wrote:
> On Mon, 30 Aug 2004, Andreas Metzler wrote:
> > Why do you need to upload to unstable at all? Is there something wrong
> > with the version in unstable? Can't you simply upload 0.6.2-3
> > unchanged (except for debian/changelog) as 0.6.2-2sarge1 to testing?
 
> Good point... I guess I wasn't sure that I could use an arbitrary low
> version number.  Testing has no "memory" of 0.6.2-3 at this point I guess.

Afaiu 0.6.2-3 was never part of sarge.
   cu andreas

Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

[Andreas Metzler]

On Mon, Aug 30, 2004 at 09:06:01AM -0700, Paul Telford wrote:
> On Sat, 28 Aug 2004, Steve Langasek wrote:
> > digikam has been removed from testing, because it depended on libexif9.
> > The version of digikam in unstable will almost certainly depend on
> > kdelibs4 3.3 once it's been successfully built on mipsel.  This means
> > the version in unstable will almost certainly not make it into sarge
> > because of KDE 3.3 not being ready in time.

> > If you want digikam to be included in sarge, please upload it to
> > testing-proposed-updates.
[...]
> The current version in unstable is 0.6.2-3.  I have built 0.6.2-4 for
> sarge (simply bumped the version #) and 0.6.2-3sarge1 for t-p-u.  I plan
> to upload the unstable version first so that sarge < unstable.

Why do you need to upload to unstable at all? Is there something wrong
with the version in unstable? Can't you simply upload 0.6.2-3
unchanged (except for debian/changelog) as 0.6.2-2sarge1 to testing?
 cu andreas

Re: Update-excuses: Makes N non-depending packages uninstallable on ...

[Andreas Metzler]

On 2004-08-30 Frank Küster <[EMAIL PROTECTED]> wrote:
> I'm wondering how to interpret, especially the last part.

> http://bjorn.haxx.se/debian/testing.pl?package=tetex-bin

> First it says:

> * Updating tetex-bin makes 3 depending packages uninstallable on alpha: 
> jbibtex-bin, jmpost, ptex-bin

> This seems to be bogus, because ptex-bin (source package of the three)
> has a versioned depends on tetex-bin that cannot be fullfilled with the
> version in sarge. 

Britney tries one package at a time, unless told otherwise (with a
"hint"). It does not try to update *both* ptex-bin and tetex-bin
together, and the version of ptex-bin in sarge does not "depends on
tetex-bin that cannot be fullfilled with the version in sarge".

> But then:

> * Updating tetex-bin makes 35 non-depending packages uninstallable on
>   alpha: acl2-infix, advi, cdcover, cjk-latex, dvidvi, dvifb, dvilib2,
[...]
> What does that mean? For the first, acl2-infix, I cannot find any
> connection to tetex-bin; for cdcover, e.g., there is one:

> Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.3-1), libstdc++5 (>= 
> 1:3.3.3-1), tetex-bin, tetex-base, tetex-extra
[...]

tetex-bin in sid "Conflicts: tetex-base (<= 2.0.2b-2)", therefore
upgrading tetex-bin on its own makes tetex-bin itself uninstallable,
therefore everything related would be, too.

We had already talked about this on IRC today, because Steve Langasek
had already hinted tetex-base and tetex-bin together but it had not
worked out, Steve traced it to:

| The following arch: all packages are broken by trying to update
| tetex: alcovebook-sgml docbook-utils jadetex sgml2x
| translate-docformat
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: gtklp-1.0pre1

[Andreas Metzler]

On 2004-08-29 "Zak B. Elep" <[EMAIL PROTECTED]> wrote:
>  gtklp (1.0pre1-1) unstable; urgency=low
[...]

I would not use this version number. You'd be forced to either use a
epoch for the real 1.0 or "1.0rel"
$ dpkg --compare-versions 0.9u-1 '<<' '1.0pre1-1' || echo not ok
$ dpkg --compare-versions 1.0-1 '>>' '1.0pre1-1' || echo not ok
not ok
$ dpkg --compare-versions 1.0rel-1 '>>' '1.0pre1-1' || echo not ok

I'd go for 0.9u+1.0pre1-1:
$ dpkg --compare-versions 0.9u-1 '<<' '0.9u+1.0pre1-1' || echo not ok
$ dpkg --compare-versions 1.0-1 '>>' '0.9u+1.0pre1-1'|| echo not ok

Which will give you a clean start for 1.0, otherwise you'll have
difficulties if upstream releases 1.0a after 1.0.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: gtklp-0.9u

[Andreas Metzler]

On 2004-08-25 "Zak B. Elep" <[EMAIL PROTECTED]> wrote:
> Hi guys, gonna make this quick, as I'm in a public Knoppix box:

> I've just finished a very *late* deb of gtklp-0.9u. Nothing really worth
> noting, except that it might get into Sarge (but, in all probability, it won't
> :()

Could you please hit upstream with a big cluebat engraved with
?

| Whichever license you plan to use, the process involves adding two
| elements to each source file of your program: a copyright notice
| (such as "Copyright 1999 Linda Jones"), and a statement of copying
| permission, saying that the program is distributed under the terms of
| the GNU General Public License (or the Lesser GPL).

Just putting a copy of the GPL in a file COPYING does not license the
software as GPL.

After that you'll be able to implement 
http://lists.debian.org/debian-devel-announce/2003/12/msg7.html
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: gtklp-0.9u

[Andreas Metzler]

On 2004-08-25 "Zak B. Elep" <[EMAIL PROTECTED]> wrote:
> Hi guys, gonna make this quick, as I'm in a public Knoppix box:

> I've just finished a very *late* deb of gtklp-0.9u. Nothing really worth
> noting, except that it might get into Sarge (but, in all probability, it won't
> :()

Could you please hit upstream with a big cluebat engraved with
?

| Whichever license you plan to use, the process involves adding two
| elements to each source file of your program: a copyright notice
| (such as "Copyright 1999 Linda Jones"), and a statement of copying
| permission, saying that the program is distributed under the terms of
| the GNU General Public License (or the Lesser GPL).

Just putting a copy of the GPL in a file COPYING does not license the
software as GPL.

After that you'll be able to implement 
http://lists.debian.org/debian-devel-announce/2003/12/msg7.html
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: kst: A KDE data analysis program

[Andreas Metzler]

On Fri, Aug 27, 2004 at 01:35:34PM +0100, Mark Hymers wrote:
[...] 
> There is a KDE NMU in incoming at the moment which fixes the libopenexr
> issue.  Could you offer me one piece of advice?  Should I make the
> Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to
> make sure buildds don't waste time trying to do it with 3.3.0-1?
[...]

No, that is useless. - It does not change a thing.

The buildds do not automatically evaluate Build-Depends before they
download and try to build the package. They download the package,
install build-dependcies (ignoring the version requirements) and only
after that check whether the version requirements are fullfilled.

Let me show you the different outcomes on a autobuilder with old
kdelibs:

* with versioned Build-Depends:
buildd downloads package and tries to install kdelibs4. apt screams
loudly because libopenexr0 is not available.

* without versioned Build-Depends:
buildd downloads package and tries to install kdelibs4. apt screams
loudly because libopenexr0 is not available.

The buildd administrators can *manually* set pre-dependencies to save
buildd time (Dep-Wait),buttheycan do that no matter how the
Build-Dependencies look like.
 cu andreas

Re: RFS: kst: A KDE data analysis program

[Andreas Metzler]

On Fri, Aug 27, 2004 at 01:35:34PM +0100, Mark Hymers wrote:
[...] 
> There is a KDE NMU in incoming at the moment which fixes the libopenexr
> issue.  Could you offer me one piece of advice?  Should I make the
> Build-Depends on kdelibs4 versioned (i.e. kdelibs4 (>> 3.3.0-1.1)) to
> make sure buildds don't waste time trying to do it with 3.3.0-1?
[...]

No, that is useless. - It does not change a thing.

The buildds do not automatically evaluate Build-Depends before they
download and try to build the package. They download the package,
install build-dependcies (ignoring the version requirements) and only
after that check whether the version requirements are fullfilled.

Let me show you the different outcomes on a autobuilder with old
kdelibs:

* with versioned Build-Depends:
buildd downloads package and tries to install kdelibs4. apt screams
loudly because libopenexr0 is not available.

* without versioned Build-Depends:
buildd downloads package and tries to install kdelibs4. apt screams
loudly because libopenexr0 is not available.

The buildd administrators can *manually* set pre-dependencies to save
buildd time (Dep-Wait),buttheycan do that no matter how the
Build-Dependencies look like.
 cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: version numbers in testing-proposed-updates (was: current specialities for NMUs)

[Andreas Metzler]

On Wed, Aug 25, 2004 at 03:28:29PM +0200, Frank Küster wrote:
> Andreas Barth <[EMAIL PROTECTED]> wrote in debian-devel:
> 
> > These packages are frozen, i.e. newer uploads to unstable won't go
> > into testing. The official way is to upload also a package to
> > testing. To upload a package to testing (or:
> > testing-proposed-updates, this are just synonyms; tpu in short),
> > it is necessary that the version number of the upload is smaller
> > than the current installed package in unstable, and larger than
> > the current installed package in testing. 
[...] 
> What version numbers are usually used?

Common practise seems to be keep using normale versioning for sid
and 1.2.3-4.sarge.1 for tpu.
  cu andreas

Re: version numbers in testing-proposed-updates (was: current specialities for NMUs)

[Andreas Metzler]

On Wed, Aug 25, 2004 at 03:28:29PM +0200, Frank Küster wrote:
> Andreas Barth <[EMAIL PROTECTED]> wrote in debian-devel:
> 
> > These packages are frozen, i.e. newer uploads to unstable won't go
> > into testing. The official way is to upload also a package to
> > testing. To upload a package to testing (or:
> > testing-proposed-updates, this are just synonyms; tpu in short),
> > it is necessary that the version number of the upload is smaller
> > than the current installed package in unstable, and larger than
> > the current installed package in testing. 
[...] 
> What version numbers are usually used?

Common practise seems to be keep using normale versioning for sid
and 1.2.3-4.sarge.1 for tpu.
  cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: irda-utils: howto dist-upgrade when package name has changed?

[Andreas Metzler]

On 2004-08-23 Sebastian Henschel <[EMAIL PROTECTED]> wrote:
[...]
> the problem is that the package(s) in stable are called irda-tools and
> irda-common and the current version is called irda-utils. when doing a
> dist-ugprade from stable to unstable, irda-tools and irda-common are
> not replaced automatically by irda-utils. how can i handle this?
> irda-utils defines:

> Replaces: irda-common, irda-tools
> Provides: irda-tools
> Conflicts: irda-common, irda-tools

> but that does not seem to suffice. is a pseudo-package irda-tools
> necessary which depends on irda-utils?

Yes, a empty pseudo package is necessary.
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: irda-utils: howto dist-upgrade when package name has changed?

[Andreas Metzler]

On 2004-08-23 Sebastian Henschel <[EMAIL PROTECTED]> wrote:
[...]
> the problem is that the package(s) in stable are called irda-tools and
> irda-common and the current version is called irda-utils. when doing a
> dist-ugprade from stable to unstable, irda-tools and irda-common are
> not replaced automatically by irda-utils. how can i handle this?
> irda-utils defines:

> Replaces: irda-common, irda-tools
> Provides: irda-tools
> Conflicts: irda-common, irda-tools

> but that does not seem to suffice. is a pseudo-package irda-tools
> necessary which depends on irda-utils?

Yes, a empty pseudo package is necessary.
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xpat2 testing excuses

[Andreas Metzler]

On 2004-08-21 Laszlo 'GCS' Boszormenyi <[EMAIL PROTECTED]> wrote:
> * Andreas Metzler <[EMAIL PROTECTED]> [2004-08-18 16:54:27 +0200]:
> > The testing scripts did not run succesfully tonight.
>  Any expected date when they will be fixed? It seems they are still
> broken, at least I do not see packages.qa.debian.org updating.

It has been fixed, but the information on p.qa.d.o is delayed by a
day, xpat2 has successfully propagated to testing:
http://packages.debian.org/xpat2
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: xpat2 testing excuses

[Andreas Metzler]

On 2004-08-21 Laszlo 'GCS' Boszormenyi <[EMAIL PROTECTED]> wrote:
> * Andreas Metzler <[EMAIL PROTECTED]> [2004-08-18 16:54:27 +0200]:
> > The testing scripts did not run succesfully tonight.
>  Any expected date when they will be fixed? It seems they are still
> broken, at least I do not see packages.qa.debian.org updating.

It has been fixed, but the information on p.qa.d.o is delayed by a
day, xpat2 has successfully propagated to testing:
http://packages.debian.org/xpat2
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xpat2 testing excuses

[Andreas Metzler]

On Wed, Aug 18, 2004 at 04:23:51PM +0200, Luk Claes wrote:
> xpat2 is installed for m68k a couple of days ago, though it isn't entering
> testing because it has "not yet built on m68k"??
> 
> It has been built 2 times according buildd.d.o, it is installed according
> to buildd.net, but waiting for a build according to bjorn.haxx.se/debian.
 
> What is going wrong or is it supposed to be like this so near the release?

The testing scripts did not run succesfully tonight.
  cu andreas

Re: xpat2 testing excuses

[Andreas Metzler]

On Wed, Aug 18, 2004 at 04:23:51PM +0200, Luk Claes wrote:
> xpat2 is installed for m68k a couple of days ago, though it isn't entering
> testing because it has "not yet built on m68k"??
> 
> It has been built 2 times according buildd.d.o, it is installed according
> to buildd.net, but waiting for a build according to bjorn.haxx.se/debian.
 
> What is going wrong or is it supposed to be like this so near the release?

The testing scripts did not run succesfully tonight.
  cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems with cylcing dependencies in sid->sarge

[Andreas Metzler]

On 2004-08-17 Christian Hammers <[EMAIL PROTECTED]> wrote:
> Two packages, libdbi-perl and libdbd-csv-perl have problems going to
> testing also each of them seems to be fine and they should be able
> to go in simultaneously. 

> Can anybody explain to me what's wrong here?
[...]

Testing does not automatically resolve situations like this (Two
packages need to go in at _exactly_ the same time, updating either one
of them separately does not work). - The release managers need to
manually add a hint. http://ftp-master.debian.org/testing/hints/

If you ever encounter this situation you should verify that the hint
not yet been added and send a mail to debian-release. - I'll try to
take care of this specific one by grabbing a RM on IRC.
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: Problems with cylcing dependencies in sid->sarge

[Andreas Metzler]

On 2004-08-17 Christian Hammers <[EMAIL PROTECTED]> wrote:
> Two packages, libdbi-perl and libdbd-csv-perl have problems going to
> testing also each of them seems to be fine and they should be able
> to go in simultaneously. 

> Can anybody explain to me what's wrong here?
[...]

Testing does not automatically resolve situations like this (Two
packages need to go in at _exactly_ the same time, updating either one
of them separately does not work). - The release managers need to
manually add a hint. http://ftp-master.debian.org/testing/hints/

If you ever encounter this situation you should verify that the hint
not yet been added and send a mail to debian-release. - I'll try to
take care of this specific one by grabbing a RM on IRC.
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On Mon, Aug 16, 2004 at 05:58:26PM +0100, John Hedges wrote:
[...]
> I've put a new copy at the above address.

I made a last minute change to debian/control and uploaded the package.

-Description: Sound player for MPEG-1,2 layer 1,2,3 Based on maplay, this
- package decodes layer I, II, and III MPEG audio streams/files and plays them
- from the command line. It can also be used to play wav files.
+Description: Sound player for MPEG-1,2 layer 1,2,3
+ Based on maplay, this package decodes layer I, II, and III MPEG audio
+ streams/files and plays them from the command line. It can also be used
+ to play wav files.

(The short description must standon its own.)

Usually I would not change a sponsored package before uploading, but I
wanted to get it in before dinstall runs, shortly before sarge time is
an issue. - I do hope that is ok for you.
cu andreas

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On Mon, Aug 16, 2004 at 05:58:26PM +0100, John Hedges wrote:
[...]
> I've put a new copy at the above address.

I made a last minute change to debian/control and uploaded the package.

-Description: Sound player for MPEG-1,2 layer 1,2,3 Based on maplay, this
- package decodes layer I, II, and III MPEG audio streams/files and plays them
- from the command line. It can also be used to play wav files.
+Description: Sound player for MPEG-1,2 layer 1,2,3
+ Based on maplay, this package decodes layer I, II, and III MPEG audio
+ streams/files and plays them from the command line. It can also be used
+ to play wav files.

(The short description must standon its own.)

Usually I would not change a sponsored package before uploading, but I
wanted to get it in before dinstall runs, shortly before sarge time is
an issue. - I do hope that is ok for you.
cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On Mon, Aug 16, 2004 at 03:24:52PM +0100, John Hedges wrote:
[...] 
> If you feel inclined to take a further look, 0.9.5.2-6 is now at
> http://www.callpoint.org/splay/

Almost ok. debian/control must not hardcode the shlibs-dependencies,
use ${shlibs:Depends} instead.
   cu andreas
PS: The pains you took for implementing nostrip was unnecessary,
dh_strip evaluates DEB_BUILD_OPTIONS. ;-)

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On Mon, Aug 16, 2004 at 03:24:52PM +0100, John Hedges wrote:
[...] 
> If you feel inclined to take a further look, 0.9.5.2-6 is now at
> http://www.callpoint.org/splay/

Almost ok. debian/control must not hardcode the shlibs-dependencies,
use ${shlibs:Depends} instead.
   cu andreas
PS: The pains you took for implementing nostrip was unnecessary,
dh_strip evaluates DEB_BUILD_OPTIONS. ;-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gprolog: buildds not touching it

[Andreas Metzler]

On 2004-08-16 Salvador Abreu <[EMAIL PROTECTED]> wrote:
> GNU Prolog (the gprolog package) is a native-code compiler with
> back-ends for several targets and *no* "generic" target: it can't work
> for a given architecture unless a back-end has been written for it.

> I've tried to deal with this with a control line:
>   Architecture: i386 amd64 sparc mips alpha powerpc
> so that it only builds on some architectures.

> The trouble is I can't get a hold of any machine of these architectures
> to make binary packages, and buildds don't seem to try to build it.

> How could I "persuade" them to try building the newer versions?

It is listed in
http://buildd.debian.org/quinn-diff/Packages-arch-specific as
i386-only, the top of the file includes instruction on who needs to be
contacted to change this.
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On 2004-08-16 John Hedges <[EMAIL PROTECTED]> wrote:
[...]
> There is a slight complication: the QA team uploaded a version that
> fixed some arch bugs by setting architecture to all [1]. I don't seem to
> be able to get the latest sources
[...]

0.9.5.2-5 is available on every mirror, e.g.
http://ftp.debian.org/debian/pool/main/s/splay/
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: gprolog: buildds not touching it

[Andreas Metzler]

On 2004-08-16 Salvador Abreu <[EMAIL PROTECTED]> wrote:
> GNU Prolog (the gprolog package) is a native-code compiler with
> back-ends for several targets and *no* "generic" target: it can't work
> for a given architecture unless a back-end has been written for it.

> I've tried to deal with this with a control line:
>   Architecture: i386 amd64 sparc mips alpha powerpc
> so that it only builds on some architectures.

> The trouble is I can't get a hold of any machine of these architectures
> to make binary packages, and buildds don't seem to try to build it.

> How could I "persuade" them to try building the newer versions?

It is listed in
http://buildd.debian.org/quinn-diff/Packages-arch-specific as
i386-only, the top of the file includes instruction on who needs to be
contacted to change this.
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: splay -- A bit better prepared now ...

[Andreas Metzler]

On 2004-08-16 John Hedges <[EMAIL PROTECTED]> wrote:
[...]
> There is a slight complication: the QA team uploaded a version that
> fixed some arch bugs by setting architecture to all [1]. I don't seem to
> be able to get the latest sources
[...]

0.9.5.2-5 is available on every mirror, e.g.
http://ftp.debian.org/debian/pool/main/s/splay/
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
[...]
> I implemented all changes you suggested and even decreased version number ;)
> New files are uploaded in ftp. Please check everyone who needs it.

Thanks, that is better. However debveinan copyright now looks as if
you were upstream author. I'd suggest this:

---
--- debian/copyright.orig   2004-08-15 21:58:40.0 +0200
+++ debian/copyright2004-08-15 22:06:04.0 +0200
@@ -1,13 +1,14 @@
 This package was debianized by Søren Boll Overgaard <[EMAIL PROTECTED]> on
 Tue, 21 May 2002 18:53:05 +0200.
+Debian maintainers:
+ 1999-2004 Søren Boll Overgaard
+ 2004 Rolandas Juodzbalis

 It was downloaded from http://www.alvie.com/download/wmnetmon/

 Upstream Author: Alvaro Lopes <[EMAIL PROTECTED]>

 Copyright 1999-2004 Alvaro Lopes. All rights reserved.
- 1999-2004 Søren Boll Overgaard (previous Debian package maintainer)
- 2004 Rolandas Juodzbalis (Debian package maintainer)
---

Another thing:
Build-Depends: debhelper (>= 4.1.16), xlibs-dev, dpatch

xlibs-dev is a pseudo-package today, use
Build-Depends: debhelper (>= 4.1.16), dpatch,libx11-dev, libxext-dev,libxpm-dev
and invoke ./configure with: --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib to make AC_PATH_X succeed without libxt.
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
[...]
> I implemented all changes you suggested and even decreased version number ;)
> New files are uploaded in ftp. Please check everyone who needs it.

Thanks, that is better. However debveinan copyright now looks as if
you were upstream author. I'd suggest this:

---
--- debian/copyright.orig   2004-08-15 21:58:40.0 +0200
+++ debian/copyright2004-08-15 22:06:04.0 +0200
@@ -1,13 +1,14 @@
 This package was debianized by Søren Boll Overgaard <[EMAIL PROTECTED]> on
 Tue, 21 May 2002 18:53:05 +0200.
+Debian maintainers:
+ 1999-2004 Søren Boll Overgaard
+ 2004 Rolandas Juodzbalis

 It was downloaded from http://www.alvie.com/download/wmnetmon/

 Upstream Author: Alvaro Lopes <[EMAIL PROTECTED]>

 Copyright 1999-2004 Alvaro Lopes. All rights reserved.
- 1999-2004 Søren Boll Overgaard (previous Debian package maintainer)
- 2004 Rolandas Juodzbalis (Debian package maintainer)
---

Another thing:
Build-Depends: debhelper (>= 4.1.16), xlibs-dev, dpatch

xlibs-dev is a pseudo-package today, use
Build-Depends: debhelper (>= 4.1.16), dpatch,libx11-dev, libxext-dev,libxpm-dev
and invoke ./configure with: --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib to make AC_PATH_X succeed without libxt.
cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> Andreas Metzler wrote:
>>On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
>>> I taked maintenance of this package from Søren Boll Overgaard, who has 
>>> no time for it.
>>> And he has no time for sponsoring this package. If someone can, please 
>>> sponsorship.
>>> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

>> debian/copyright needs to be fixed to implement
>> http://lists.debian.org/debian-devel-announce/2003/12/msg7.html

>> It should also list the previous maintainer.

> Thanks for reviewing it. I readed that announce about bad copyright
> files.  But there is no such info who has copyrigth on wmnetmon.

Indeed most of the files are missing copyright notices, however
wmnetmon.c includes one. - It specifies GPLv2 (or later.)

> Especially years. Will be enough to add copyright to author without
> year?
> And where previous maintainer should be listed in copyright file?

Something like:
Previous Debian maintainers: Søren Boll Overgaard
would be enough, imho.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> Andreas Metzler wrote:
>>On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
>>> I taked maintenance of this package from Søren Boll Overgaard, who has 
>>> no time for it.
>>> And he has no time for sponsoring this package. If someone can, please 
>>> sponsorship.
>>> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

>> debian/copyright needs to be fixed to implement
>> http://lists.debian.org/debian-devel-announce/2003/12/msg7.html

>> It should also list the previous maintainer.

> Thanks for reviewing it. I readed that announce about bad copyright
> files.  But there is no such info who has copyrigth on wmnetmon.

Indeed most of the files are missing copyright notices, however
wmnetmon.c includes one. - It specifies GPLv2 (or later.)

> Especially years. Will be enough to add copyright to author without
> year?
> And where previous maintainer should be listed in copyright file?

Something like:
Previous Debian maintainers: Søren Boll Overgaard
would be enough, imho.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> I taked maintenance of this package from Søren Boll Overgaard, who has no 
> time for it.
> And he has no time for sponsoring this package. If someone can, please 
> sponsorship.
> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

debian/copyright needs to be fixed to implement
http://lists.debian.org/debian-devel-announce/2003/12/msg7.html

It should also list the previous maintainer.
cu andreas

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> I taked maintenance of this package from Søren Boll Overgaard, who has no 
> time for it.
> And he has no time for sponsoring this package. If someone can, please 
> sponsorship.
> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

The package is built as native package. (just tar.gz instead of
orig.tar.gz + diff.gz) - Make sure the original sources are in the
parent of the build-dir with the correct filename
(name_version.orig.tar.gz) before you start the build.

Additionally you need to build the package with 
dpkg-buildpackage -v0.2p5-12
to get the changelogs for 0.2p5-13 and 0.2p5-14 into changes file and
get the bugs closed. (Your sponsor will rebuilt the package, make him
aware of this issue.)

Looks like you have fixed debian/templates (s/packages/packets/) (No
note in debian/changelog?) making the new Japanese translation out of
date. - How about sending a mail to him and asking him to fix it? -
He'll probably just need to remove the fuzzy-marker.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> I taked maintenance of this package from Søren Boll Overgaard, who has no 
> time for it.
> And he has no time for sponsoring this package. If someone can, please 
> sponsorship.
> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

debian/copyright needs to be fixed to implement
http://lists.debian.org/debian-devel-announce/2003/12/msg7.html

It should also list the previous maintainer.
cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmnetmon - new maintainer

[Andreas Metzler]

On 2004-08-15 Rolandas Juodzbalis <[EMAIL PROTECTED]> wrote:
> I taked maintenance of this package from Søren Boll Overgaard, who has no 
> time for it.
> And he has no time for sponsoring this package. If someone can, please 
> sponsorship.
> New package is located at ftp://ftp.home.lt/pub/debian/packages/wmnetmon

The package is built as native package. (just tar.gz instead of
orig.tar.gz + diff.gz) - Make sure the original sources are in the
parent of the build-dir with the correct filename
(name_version.orig.tar.gz) before you start the build.

Additionally you need to build the package with 
dpkg-buildpackage -v0.2p5-12
to get the changelogs for 0.2p5-13 and 0.2p5-14 into changes file and
get the bugs closed. (Your sponsor will rebuilt the package, make him
aware of this issue.)

Looks like you have fixed debian/templates (s/packages/packets/) (No
note in debian/changelog?) making the new Japanese translation out of
date. - How about sending a mail to him and asking him to fix it? -
He'll probably just need to remove the fuzzy-marker.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how buildd's work?

[Andreas Metzler]

On 2004-08-06 Laszlo 'GCS' Boszormenyi <[EMAIL PROTECTED]> wrote:
>  I contributed a very small amount to the subversion package. What I see
> from packages.qa.debian.org is that building it on alpha and other archs
> are failed as the newest apache2 cause trouble with the dependencies.
> The problem is that apache2 has an arch=all part, and arch=any ones as
> well; the arch=all part installed for the subversion dependency, but the
> arch=any parts are not available. Looking into apache2 build logs, I see
> on alpha and other archs it is not even tried to build. How that can
> happen if apache2 uploaded a day earlier than subversion, however
> apache2 is not even tried to build, but subversion is tried?

Check http://buildd.debian.org/stats/graph-week.png to see *how*
overloaded our buildds currently are. See
http://lists.debian.org/debian-devel/2004/07/msg01555.html for how
builds are ordered, especially note the facts that dependoncies are not
evaluated before scheduling a build.

>  If I would be a Debian Developer, what I could do to resolve such
> situations (I mean for example to force the apache2 build)?

You'd either wait or try to find somebody with a alpha nachine and ask
him to build it manually. Because two days to early to pester
[EMAIL PROTECTED] and because the are ridiculously overloaded
currently.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: how buildd's work?

[Andreas Metzler]

On 2004-08-06 Laszlo 'GCS' Boszormenyi <[EMAIL PROTECTED]> wrote:
>  I contributed a very small amount to the subversion package. What I see
> from packages.qa.debian.org is that building it on alpha and other archs
> are failed as the newest apache2 cause trouble with the dependencies.
> The problem is that apache2 has an arch=all part, and arch=any ones as
> well; the arch=all part installed for the subversion dependency, but the
> arch=any parts are not available. Looking into apache2 build logs, I see
> on alpha and other archs it is not even tried to build. How that can
> happen if apache2 uploaded a day earlier than subversion, however
> apache2 is not even tried to build, but subversion is tried?

Check http://buildd.debian.org/stats/graph-week.png to see *how*
overloaded our buildds currently are. See
http://lists.debian.org/debian-devel/2004/07/msg01555.html for how
builds are ordered, especially note the facts that dependoncies are not
evaluated before scheduling a build.

>  If I would be a Debian Developer, what I could do to resolve such
> situations (I mean for example to force the apache2 build)?

You'd either wait or try to find somebody with a alpha nachine and ask
him to build it manually. Because two days to early to pester
[EMAIL PROTECTED] and because the are ridiculously overloaded
currently.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: simple cron packaging question

[Andreas Metzler]

On 2004-08-05 Brian Sutherland <[EMAIL PROTECTED]> wrote:
> As my first foray into debian packaging, I want to create a
> package that installs a cron job to be run daily.

> My approach is to install a simple script into /etc/cron.daily/
> that calls a more complex script which I install into /usr/bin/.

> Will this be compliant with the FHS?

Why not?

> Make sure that if the package is uninstalled, the cron job is
> disabled?

You have to take care of that yourself, e.g. by starting
/etc/cron.daily/script with
if ! test -x /usr/bin/complexscript ; then
   exit 0
fi

   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: simple cron packaging question

[Andreas Metzler]

On 2004-08-05 Brian Sutherland <[EMAIL PROTECTED]> wrote:
> As my first foray into debian packaging, I want to create a
> package that installs a cron job to be run daily.

> My approach is to install a simple script into /etc/cron.daily/
> that calls a more complex script which I install into /usr/bin/.

> Will this be compliant with the FHS?

Why not?

> Make sure that if the package is uninstalled, the cron job is
> disabled?

You have to take care of that yourself, e.g. by starting
/etc/cron.daily/script with
if ! test -x /usr/bin/complexscript ; then
   exit 0
fi

   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildds

[Andreas Metzler]

On 2004-08-05 Alexander List <[EMAIL PROTECTED]> wrote:
> I uploaded a non-free package (diablo) two days ago and wonder what
> I can do to make the buillds attempt to build it for all the
> non-i386 archs...

The autobuilders will not build nonfree packages no matter what you
try. - You can build manually on one of Debian's machines if you are
a DD.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: buildds

[Andreas Metzler]

On 2004-08-05 Alexander List <[EMAIL PROTECTED]> wrote:
> I uploaded a non-free package (diablo) two days ago and wonder what
> I can do to make the buillds attempt to build it for all the
> non-i386 archs...

The autobuilders will not build nonfree packages no matter what you
try. - You can build manually on one of Debian's machines if you are
a DD.
  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to retire a bug tagged wontfix,woody?

[Andreas Metzler]

On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote:
> I am the (new) maintainer for mozart. I have one Serious bug
> outstanding:
> 
>http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). 
> 
> The bug was tagged wontfix, woody.  The bug has been fixed in versions
> later than woody.  What should I do? Will this just hang around
> forever?
[...]

Basically that is up to you as maintainer. Having open bugs in the BTS
tagged woody that you are not going to fix only serves one purpose:
documentation. If you do not think this is necessary close it.

Personally, for this specific bug I'd keep it open just a little bit
longer until sarge is released.
  cu andreas

Re: How to retire a bug tagged wontfix,woody?

[Andreas Metzler]

On Mon, Aug 02, 2004 at 03:03:31PM +0200, Kevin Glynn wrote:
> I am the (new) maintainer for mozart. I have one Serious bug
> outstanding:
> 
>http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mozart). 
> 
> The bug was tagged wontfix, woody.  The bug has been fixed in versions
> later than woody.  What should I do? Will this just hang around
> forever?
[...]

Basically that is up to you as maintainer. Having open bugs in the BTS
tagged woody that you are not going to fix only serves one purpose:
documentation. If you do not think this is necessary close it.

Personally, for this specific bug I'd keep it open just a little bit
longer until sarge is released.
  cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]