New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi, today I've seen the first time this new lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team I wonder whether we could this set from severity Warning to Pedandic. The point is that this address works not only as maintainer but rather as key in several infrastrutural use case like database queries etc. The only reason that would convince me that a change is needed would be that the redirect to alioth-lists.debian.net would not work any more at some foreseable point of time. So please note: I would not mind about automatically replacing that address with something non-obsolete since we try to do some turnover of all (about 1000) Debian Med packages per release. But once we start this change several tools will stop working reliably. This is to much effort for something that looks cosmetical in my eyes. So if you insist that this should be at severity warning I'll probably rather add a lintian override automatically for all our packages rather than automatically change the maintainer address. Kind regards Andreas. -- http://fam-tille.de
lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
package: lintian version: 2.67.0 x-debbugs-cc: Debian Med Project List , Debian Developers , Debian Lintian Maintainers , reproducible-bui...@lists.alioth.debian.org On Fri, Apr 24, 2020 at 09:56:24AM +0200, Andreas Tille wrote: > today I've seen the first time this new lintian warning: > >mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team > > > I wonder whether we could this set from severity Warning to Pedandic. definitly, yes, filing this bug now. > The point is that this address works not only as maintainer but rather > as key in several infrastrutural use case like database queries etc. > The only reason that would convince me that a change is needed would be > that the redirect to alioth-lists.debian.net would not work any more at > some foreseable point of time. So please note: I would not mind about > automatically replacing that address with something non-obsolete since > we try to do some turnover of all (about 1000) Debian Med packages per > release. But once we start this change several tools will stop working > reliably. This is to much effort for something that looks cosmetical in > my eyes. So if you insist that this should be at severity warning I'll > probably rather add a lintian override automatically for all our > packages rather than automatically change the maintainer address. we also still use reproducible-bui...@lists.alioth.debian.org as our maintainer address for Reproducible Builds related packages and it's our advertised point of contact for Debian related Reproducible Builds stuff and we don't have any plan to change this any time soon. It's true that some @lists.alioth.debian.org stopped working but *many* have been migrated to alioth-lists.debian.net and continue to work as @lists.alioth.debian.org so this lintian warning creates tons of non-actionable and doubtful (not to say false-positive) warnings. Please change this and thank you for maintaining lintian! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Andreas, > I wonder whether we could this set from severity Warning to Pedandic. This was already done in: https://salsa.debian.org/lintian/lintian/commit/fd8ee67d96c713698f4c5e08eea0b0dafe02bdf4 > […] So if you insist that this should be at severity warning I'll > probably rather add a lintian override automatically for all our > packages rather than automatically change the maintainer address. Maybe you've just caught me in a grumpy mood this morning, but personally I enjoy developing and maintaining Lintian a lot more when I don't feel I am being emotionally manipulated. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
tags 958666 + pending thanks Holger Levsen wrote: > definitly, yes, filing this bug now. As mentioned elsewhere, this was already fixed yesterday in fd8ee67d. -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, Apr 24, 2020 at 10:22:22AM +0100, Chris Lamb wrote: > > definitly, yes, filing this bug now. > As mentioned elsewhere, this was already fixed yesterday in fd8ee67d. ah, cool! & thanks for the quick fix! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, 24 Apr 2020 10:22:22 +0100, Chris Lamb wrote: > Holger Levsen wrote: > > definitly, yes, filing this bug now. > As mentioned elsewhere, this was already fixed yesterday in fd8ee67d. Thank you, a lowered severity is of course better. But to be honest, it doesn't change a lot if I'm seeing "W: $package source: mailing-list-obsolete-in-debian-infrastructure Debian Perl Group " or "I: $package source: mailing-list-obsolete-in-debian-infrastructure Debian Perl Group " each single time I build a perl package (ok, the colour is nicer :)). In my personal opinion, this lintian warning/info is not actionable, also the referred to wiki page at https://wiki.debian.org/Alioth/MailingListContinuation doesn't say anything about not using @lists.alioth.debian.org or what to replace it with, and unless the maintainers of the replacement system tell us otherwise, I assume this will all keep working fine. So personally, I'd rather see this lintian tag dropped completely. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Alannah Myles signature.asc Description: Digital Signature
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, Apr 24, 2020 at 11:46:47AM +0200, gregor herrmann wrote: > On Fri, 24 Apr 2020 10:22:22 +0100, Chris Lamb wrote: > Thank you, a lowered severity is of course better. > > > But to be honest, it doesn't change a lot if I'm seeing > > "W: $package source: mailing-list-obsolete-in-debian-infrastructure Debian > Perl Group " > > or > > "I: $package source: mailing-list-obsolete-in-debian-infrastructure Debian > Perl Group " > > each single time I build a perl package (ok, the colour is nicer :)). That's why I suggested "Pedantic" :-P I admit Pedantic is not on my normal radar - but Info is and I would also generate an lintian-override for it. > So personally, I'd rather see this lintian tag dropped completely. Also fine for me. Kind regards Andreas. -- http://fam-tille.de
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi Chris. On Fri, Apr 24, 2020 at 09:55:52AM +0100, Chris Lamb wrote: > Andreas, > > > I wonder whether we could this set from severity Warning to Pedandic. > > This was already done in: > > > https://salsa.debian.org/lintian/lintian/commit/fd8ee67d96c713698f4c5e08eea0b0dafe02bdf4 Not really (as Gregor pointed out since Info is also on the radar). > > […] So if you insist that this should be at severity warning I'll > > probably rather add a lintian override automatically for all our > > packages rather than automatically change the maintainer address. > > Maybe you've just caught me in a grumpy mood this morning, but > personally I enjoy developing and maintaining Lintian a lot more when > I don't feel I am being emotionally manipulated. Thanks for the imediate response of your feelings. That's very appreciated to make sure social friction will not increase. I admit that I realise just now that my mail could be interpreted as emotional manipulation. This was by no means intended but may be I should think about next time first about this kind of effect. I rather was considering what the right course of action for our team would be. On one hand my goal is to have lintian clean packages up to level Info. On the other hand this lintian issue is not helpful for us in general (but may be for others?) So before anybody of the team might start "fixing" the lintian issue and by doing so breaking some tools I wanted to explain what might be a more sensible approach in *our* case. Sorry that I had my focus only on the Debian Med team side and forgot to consider lintian maintainers side. As I told several times I really appreciate your work since it is extremely helpful. To give another example where we are using a "team wide" lintian-override: https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/lintian-overrides I admit I *personally* *really* hate this since I think I perfectly subscribe all those good reasons to not add language extensions. I've written lots of mails to upstreams just to learn that I'm mostly ignored. If we follow this policy suggestion in our packages we are breaking so much user applications that a part of our user base might consider switching away from Debian. So we are making this compromise in our team *only* since it just does not fit. However, this is by no means against a very sensible lintian warning in Debian in general. Kind regards and thanks again for maintaining lintian Andreas. -- http://fam-tille.de
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi Andreas, On Fri, Apr 24, 2020 at 5:57 AM Andreas Tille wrote: > > I've written lots of mails to upstreams just to learn > that I'm mostly ignored. You are facing the dilemma of #907727, except a change would also negatively impact your users. Lintian may in the future automatically reduce the visibility of some tags (aka severity) when a maintainer can do nothing about them. Does that sound like an attractive proposition? Kind regards Felix Lechner
RFS : new upstream version of jebl2
Hi, I have packaged the new upstream version of jebl2 and made various changes. Now the packaging is in Salsa [1], could someone please check and upload it when time permits? The changes are * New upstream version 0.1+git20190308 * Deleting now useless patch source_8.patch * Bumping Standard version to 4.5.0 (adding Rules-Requires-Root field) * Marking the binary packages Multi-Arch: foreign * Using secure URL in debian/copyright * Dropping debian/compat file, using debhelper-compat * Trimming trailing whitespaces * Adding salsa-ci.yml file * Correcting path in debian/libjebl2-java-doc.javadoc * Adding and documenting lintian overrides. Thanks a lot in advance, Best, Pierre [1] https://salsa.debian.org/med-team/jebl2
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
[replacing lintian-ma...@debian.org → 958...@bugs.debian.org] Andreas Tille wrote: > > This was already done in: […] > Not really (as Gregor pointed out since Info is also on the radar). I've just marked the tag as "experimental". This has the same practical effect of it being removed. > To give another example where we are using a "team wide" > lintian-override: […] > I admit I *personally* *really* hate this since I think I perfectly > subscribe all those good reasons to not add language extensions. I share your dislike. Please file a separate wishlist bug for this — I would certainly entertain arguments to add logic to Lintian in order to spare this boilerplate within the Med team. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: Bug#958666: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi, On Fri, Apr 24, 2020 at 10:24 AM Chris Lamb wrote: > > in order to spare this boilerplate within the Med team. Wouldn't it be better to lower the severity for scripts shipped by upstream (vs the maintainer)? Kind regards Felix Lechner
Re: Idea wanted: What is the most key open source projects to fight COVID-19?
> > https://github.com/nf-core/nanoseq/blob/master/bin/scrape_software_versions.py
> > guppy
> Missing in Debian. Is it this project
>https://staff.aist.go.jp/yutaka.ueno/guppy/ ?
Hi, Andreas,
No, it seems that guppy is a base caller provided by Oxford Nanopore
technologies.
```
$ pwd
/home/jaruga/git/nf-core/nanoseq
$ grep -r guppy *
...
conf/base.config: container = 'genomicpariscentre/guppy-gpu:3.4.4'
conf/base.config: container = 'genomicpariscentre/guppy:3.4.4'
...
Then check the containers Dockerfile.
https://hub.docker.com/r/genomicpariscentre/guppy/dockerfile
> wget -q
> https://mirror.oxfordnanoportal.com/software/analysis/ont_guppy_cpu_${PACKAGE_VERSION}-1~xenial_amd64.deb
https://hub.docker.com/r/genomicpariscentre/guppy-gpu/dockerfile
> wget -q
> https://mirror.oxfordnanoportal.com/software/analysis/ont_guppy_${PACKAGE_VERSION}-1~xenial_amd64.deb
```
It might not be open source software, seeing the following page.
Here is a user's page about guppy in Japanese. I could not find the
English page.
You can see the guppy's screen shot on
https://community.nanoporetech.com/downloads page.
http://kazumaxneo.hatenablog.com/entry/2020/01/19/145940
> Thanks again Jun for your very helpful contribution
You are welcome. Let me comment on your comments later.
Cheers,
Jun
--
Jun | He - His - Him
Re: RFS : new upstream version of jebl2
Hi Pierre, thanks a lot for your work. I usually would leave the commit ID inside the version number (so 0.1+git20190308.a98448e) since this would silence the new upstream available check - but I guess you thought about this and left it as is when uploaded. Work on Java packages is extremely welcome since we have an unfortunate lack of Java knowledge in the team. If you need some inspiration what task to tackle next - I'm happy to hand over other Java tasks. ;-) Thanks again Andreas. On Fri, Apr 24, 2020 at 05:51:33PM +0200, Pierre Gruet wrote: > Hi, > > I have packaged the new upstream version of jebl2 and made various changes. > Now the packaging is in Salsa [1], could someone please check and upload it > when time permits? > > The changes are > * New upstream version 0.1+git20190308 > * Deleting now useless patch source_8.patch > * Bumping Standard version to 4.5.0 (adding Rules-Requires-Root field) > * Marking the binary packages Multi-Arch: foreign > * Using secure URL in debian/copyright > * Dropping debian/compat file, using debhelper-compat > * Trimming trailing whitespaces > * Adding salsa-ci.yml file > * Correcting path in debian/libjebl2-java-doc.javadoc > * Adding and documenting lintian overrides. > > > Thanks a lot in advance, > > Best, > Pierre > > [1] https://salsa.debian.org/med-team/jebl2 > > -- http://fam-tille.de
Re: RFS : new upstream version of jebl2
Hi Andreas, Le 24/04/2020 à 22:34, Andreas Tille a écrit : > Hi Pierre, > > thanks a lot for your work. I usually would leave the commit ID inside > the version number (so 0.1+git20190308.a98448e) since this would silence > the new upstream available check - but I guess you thought about this > and left it as is when uploaded. > Thanks for the review and the upload. I must admit I had not thought about the new upstream message that would remain... I only considered keeping the meaningful, ``understandable'' part of the version number. I will consider this choice next time. > > Work on Java packages is extremely welcome since we have an unfortunate > lack of Java knowledge in the team. If you need some inspiration what > task to tackle next - I'm happy to hand over other Java tasks. ;-) > I'm taking note! I will thus consider working on other Java packages then. > > Thanks again > > Andreas. > Have a nice week-end, Pierre
Re: RFS : new upstream version of jebl2
Hi Pierre, On Fri, Apr 24, 2020 at 11:17:40PM +0200, Pierre Gruet wrote: > > Thanks for the review and the upload. I must admit I had not thought about > the new upstream message that would remain... I only considered keeping the > meaningful, ``understandable'' part of the version number. I will consider > this choice next time. OK, I'd suggest just to leave the version number delivered by uscan. But this has time for a next upload. > > Work on Java packages is extremely welcome since we have an unfortunate > > lack of Java knowledge in the team. If you need some inspiration what > > task to tackle next - I'm happy to hand over other Java tasks. ;-) > > I'm taking note! I will thus consider working on other Java packages then. The most important task would be to package the dependencies for snpeff. I wrote down what I found out in d/changelog in salsa: https://salsa.debian.org/med-team/snpeff/-/blob/master/debian/changelog If you would manage to tackle only one of these that would be really helpful. > Have a nice week-end, Same to you Andreas. -- http://fam-tille.de
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
> Andreas Tille wrote: > > > I admit I *personally* *really* hate this since I think I perfectly > > subscribe all those good reasons to not add language extensions. Le Fri, Apr 24, 2020 at 06:13:45PM +0100, Chris Lamb a écrit : > > I share your dislike. Please file a separate wishlist bug for this — I > would certainly entertain arguments to add logic to Lintian in order > to spare this boilerplate within the Med team. Hi all, we already have https://bugs.debian.org/190753 A lot of time has passed, and most of the Policy delegates and Technical Committee members have changed. Maybe we can solve the problem by finally relaxing the policy to allow us to do exactly what we are doing now: ignoring the call to rename programs when the main outcome is to break our users scripts, our upstreams documentations, and sometimes our own packages. "Reproducible research" is now mainstream and I feel so frustrated that Debian is the only distribution in the world that insists on deliberately becoming incompatible, by changing programs names arbitrarly. The goal of this policy was to make it easier to rewrite a program from one language to another language while keeping a compatible interface. We now have more than 15 years of experience on that matter with scientific software and my conclusion is: it never happens. Have a nice week-end Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: New lintian warning: mailing-list-obsolete-in-debian-infrastructure Debian Med Packaging Team
Hi Charles, On Sat, Apr 25, 2020 at 07:40:59AM +0900, Charles Plessy wrote: > > The goal of this policy was to make it easier to rewrite a program from > one language to another language while keeping a compatible interface. > We now have more than 15 years of experience on that matter with > scientific software and my conclusion is: it never happens. while I'm meanwhile convinced that we should not remove the extension but please be carefully with your arguments: The truth ist it _rarely_ happens. The "never" can be falsified by a single example which I personally experienced and had to discussed with upstream which one is the right one to distribute. I do not remember the software but if you really want to know I check my mailbox on Monday. Kind regards Andreas. -- http://fam-tille.de
Bug#958763: lintian: Please allow language extensions in packages for specific teams
Package: lintian Version: 2.67.0 Severity: wishlist Hi, as suggested by Chris Lamb I hereby asking for either ignoring or setting severity to either experimental or pedantic for certain teams for the issue script-with-language-extension This should happen for the teams Debian Med Packaging Team Debian Science Team Kind regards and thanks for maintaining lintian Andreas. [1] https://lists.debian.org/debian-med/2020/04/msg00248.html -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.34-5 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.38-4 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libcpanel-json-xs-perl 4.19-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libjson-maybexs-perl 1.004000-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libsereal-decoder-perl 4.011+ds-1 ii libsereal-encoder-perl 4.011+ds-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3200-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.010001-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libxml-writer-perl 0.625-1 ii libyaml-libyaml-perl 0.81+repack-1 ii man-db 2.9.1-1 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-10 ii t1utils 1.41-3 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: ii binutils-multiarch 2.34-5 ii libtext-template-perl 1.58-1 -- no debconf information
