Re: Lintian is complaining about udebs?
On 2020-03-21 00:39 -0400, Theodore Y. Ts'o wrote: > Just checking --- this looks like a Really Bad regression in Lintian > 2.57.0, correct? Seems so, I can can confirm it with Lintian 2.58.0. > E: e2fsprogs-udeb udeb: debian-changelog-file-missing > E: e2fsprogs buildinfo: field-too-long Installed-Build-Depends (5090 chars > > 5000) > E: e2fsprogs-udeb udeb: file-in-etc-not-marked-as-conffile etc/mke2fs.conf > E: e2fsprogs-udeb udeb: no-copyright-file > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/badblocks > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/e2fsck > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/e2label > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/e2mmpstatus > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/fsck.ext2 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/fsck.ext3 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/fsck.ext4 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/mke2fs > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/mkfs.ext2 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/mkfs.ext3 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/mkfs.ext4 > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/resize2fs > W: e2fsprogs-udeb udeb: binary-without-manpage sbin/tune2fs > N: 5 tags overridden (2 errors, 3 info) > > By *definition* udebs aren't supposed to have changelogs, copyright > files, or man pages, right? Right. Cheers, Sven
Bug#954406: ITP: parlatype-libreoffice-extension -- Control Parlatype from LibreOffice
Package: wnpp Severity: wishlist Owner: Gabor Karsay * Package name: parlatype-libreoffice-extension Version : 2.0 Upstream Author : Gabor Karsay * URL : http://www.parlatype.org/ * License : GPL-3+ Programming Lang: Python Description : Control Parlatype from LibreOffice Controls Parlatype from within LibreOffice. Adds a toolbar to link the current media file to the document and lets Parlatype go to timestamps on mouseclick or key navigation. A set of macros can be assigned to shortcuts, e.g. inserting timestamps. The Parlatype source package provided a set of LibreOffice macros through its parlatype-libreoffice-helpers package. Those macros were turned into an extension and split off from the source package. parlatype-libreoffice-extension supersedes parlatype-libreoffice-helpers. I am upstream author and in Debian sponsored maintainer of Parlatype.
Fwd: bind9_9.11.17+dfsg-1_amd64.changes REJECTED
Hi, This seems like a regression to me, but before I fill a bug with lintian, is there anything I can do to my packages to fix this? Maybe I am doing something wrong and new lintian caught that... Ondrej -- Ondřej Surý Begin forwarded message: > From: Debian FTP Masters > Date: 21 March 2020 at 12:35:45 CET > To: Debian DNS Team , Ondřej Surý > > Subject: bind9_9.11.17+dfsg-1_amd64.changes REJECTED > > > > libbind9-161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libbind9-161/changelog.Debian.gz', automatically rejected > package. > libbind9-161: If you have a good reason, you may override this lintian tag. > libbind9-161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libbind9-161/changelog.gz', automatically rejected package. > libbind9-161: If you have a good reason, you may override this lintian tag. > libdns1110: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libdns1110/changelog.Debian.gz', automatically rejected package. > libdns1110: If you have a good reason, you may override this lintian tag. > libdns1110: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libdns1110/changelog.gz', automatically rejected package. > libdns1110: If you have a good reason, you may override this lintian tag. > libirs161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libirs161/changelog.Debian.gz', automatically rejected package. > libirs161: If you have a good reason, you may override this lintian tag. > libirs161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libirs161/changelog.gz', automatically rejected package. > libirs161: If you have a good reason, you may override this lintian tag. > libisc-export1105: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisc-export1105/changelog.Debian.gz', automatically rejected > package. > libisc-export1105: If you have a good reason, you may override this lintian > tag. > libisc-export1105: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisc-export1105/changelog.gz', automatically rejected package. > libisc-export1105: If you have a good reason, you may override this lintian > tag. > libisc1105: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisc1105/changelog.Debian.gz', automatically rejected package. > libisc1105: If you have a good reason, you may override this lintian tag. > libisc1105: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisc1105/changelog.gz', automatically rejected package. > libisc1105: If you have a good reason, you may override this lintian tag. > libisccc-export161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccc-export161/changelog.Debian.gz', automatically rejected > package. > libisccc-export161: If you have a good reason, you may override this lintian > tag. > libisccc-export161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccc-export161/changelog.gz', automatically rejected > package. > libisccc-export161: If you have a good reason, you may override this lintian > tag. > libisccc161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccc161/changelog.Debian.gz', automatically rejected > package. > libisccc161: If you have a good reason, you may override this lintian tag. > libisccc161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccc161/changelog.gz', automatically rejected package. > libisccc161: If you have a good reason, you may override this lintian tag. > libisccfg163: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccfg163/changelog.Debian.gz', automatically rejected > package. > libisccfg163: If you have a good reason, you may override this lintian tag. > libisccfg163: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/libisccfg163/changelog.gz', automatically rejected package. > libisccfg163: If you have a good reason, you may override this lintian tag. > liblwres161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/liblwres161/changelog.Debian.gz', automatically rejected > package. > liblwres161: If you have a good reason, you may override this lintian tag. > liblwres161: lintian output: 'gzip-file-is-not-multi-arch-same-safe > usr/share/doc/liblwres161/changelog.gz', automatically rejected package. > liblwres161: If you have a good reason, you may override this lintian tag. > > binary:libdns-export1110 is NEW. > binary:libdns-export1110-udeb is NEW. > binary:libdns1110 is NEW. > binary:libdns-export1110 is NEW. > binary:libdns-export1110-udeb is NEW. > binary:libdns1110 is NEW. > bind9_9.11.17+dfsg.orig.tar.xz is only available in NEW. > bind9_9.11.17+dfsg.orig.tar.xz is only available in NEW. > > === > > Please feel free to respond to this email if you don't under
Re: Fwd: bind9_9.11.17+dfsg-1_amd64.changes REJECTED
On 3/21/20 1:29 PM, Ondřej Surý wrote: > This seems like a regression to me, but before I fill a bug with lintian, is > there anything I can do to my packages to fix this? It's fixed in lintian (2.58.0), see: https://bugs.debian.org/954146 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: bind9_9.11.17+dfsg-1_amd64.changes REJECTED
Oh thanks, so I’ll just wait a bit until it’s deployed on the ftp-master queue. Ondrej -- Ondřej Surý ond...@sury.org > On 21 Mar 2020, at 13:44, Sebastiaan Couwenberg wrote: > > On 3/21/20 1:29 PM, Ondřej Surý wrote: >> This seems like a regression to me, but before I fill a bug with lintian, is >> there anything I can do to my packages to fix this? > It's fixed in lintian (2.58.0), see: > > https://bugs.debian.org/954146 > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > signature.asc Description: Message signed with OpenPGP
Re: Lintian is complaining about udebs?
On Sat, Mar 21, 2020 at 09:09:41AM +0100, Sven Joachim wrote: > On 2020-03-21 00:39 -0400, Theodore Y. Ts'o wrote: > > > Just checking --- this looks like a Really Bad regression in Lintian > > 2.57.0, correct? > > Seems so, I can can confirm it with Lintian 2.58.0. Oops, sorry, this first showed up in 2.58.0, not 2.57.0. I'll file a bug; I was just really surprised no one else had noticed this, since it was a pretty obvious/blatent failure. - Ted
Re: Python related autopkgtest anti-pattern
On Saturday, March 21, 2020 1:41:14 AM EDT Scott Kitterman wrote: > On Wednesday, March 18, 2020 6:32:22 PM EDT Scott Kitterman wrote: > > I'm currently reviewing some of the autopkgtest regressions that are > > currently blocking python3-defaults with python3.8 as the default python3 > > from migrating. > > > > With the current state of the environment being used for autopkgtest it is > > quite common for python3.7 to be present in the environment even if it's > > not explicitly required by a dependency. As a result, I seen many > > failures where the test attempts to loop through python3 versions (a good > > thing) based on what versions are installed (bad thing). > > > > We want the tests to run against all versions, but the way to do that is > > to > > have your test depend on python3-all (to make sure that all supported > > versions are installed) and then use the -s flag for py3versions vice -i. > > So (in one common pattern) this: > > > > for py in $(py3versions -i); do > > > > changes to: > > > > for py in $(py3versions -s); do > > > > Makes all the difference in the world. I've fixed three today. If you > > care for a relevant package, please check. The future pain you save may > > be your own. > > > > Scott K > > I have continued to look into this and it's common enough that there are > quite a few related autopkgtest failures currently marked as regressions > against python3-defaults with python3.8 as the default python3. > > Except for one I filed earlier, none of them have bugs currently. It's > enough I'm not sure if it qualifies as a MBF for not. Here's what I'll > file if I get sufficiently motivated and have the time: > > This package failed a recent autopkgtest and this is one of the blockers for > python3-defaults migration. It failed because python3.7 was installed in > the chroot and the current autopkgtest doesn't handle that. > > Autopkgtests should be run for all supported versions. The package attempts > to do that, but in a way that is unreliable. > > Based on a review of the failure log (I have not looked at the package, so > there's a small chance the root cause is different), the autopkgtest uses > the output of py3versions -i to iterate over available python3 versions. > The -i flag indicates all installed versions. In many cases python3.7 is > still partially installed, so it is included in the tests, but fails. > > The reliable way to do this is add python3-all to your tests depends in > debian/tests/control and change the py3versions call to py3versions -s. > These two steps will ensure all supported python3 interpreters are fully > installed and that the tests are run against them. > > As this is a blocker for getting python3.8 as default python3 into bullseye, > please address this soon. I'm open to doing NMUs if anyone would like the > support. Please let me know if you would like for me to do that. > > Scott K > > dd-list is attached. If any of you fix these before I file the bugs, please > let me know so I can skip that package when I do. > > Scott K These are filed now (it turned out one package already had a bug, so I added information to it instead of filing a new bug). Scott K ariba Added info to #951944 editorconfig-core-py#954461 m2crypto#954462 pydbus #954467 pyethash#954468 pyrlp #954469 pysha3 #954470 pystemd #954471 python-daemon #954473 python-h2 #954474 python-jsbeautifier #954476 python-jsonext #954477 python-pbkdf2 #954478 python-pynvim #954479 python-tinyrpc #954480 python3-proselint #954481 pyx3#954482 wand#954483 signature.asc Description: This is a digitally signed message part.
Is comma operator defined by POSIX and supported by dash?
Hello, According to [Bashism Wiki](https://mywiki.wooledge.org/Bashism): The comma operator is widely supported by almost everything except dash and yash -- even posh and Busybox. In ksh93 however, it conflicts with the decimal radix in locales where it's used in floating points instead of period Does it implied that arithmetic comma operator (`,`) isn't defined by POSIX shell specification? Does dash support it? Bagas -- An old man doll... just what I always wanted! - Clara
Re: Is comma operator defined by POSIX and supported by dash?
On 2020-03-22 Bagas Sanjaya wrote: > Hello, > According to [Bashism Wiki](https://mywiki.wooledge.org/Bashism): >> The comma operator is widely supported by almost everything except dash >> and yash -- even posh and Busybox. In ksh93 however, it conflicts with >> the decimal radix in locales where it's used in floating points instead >> of period > Does it implied that arithmetic comma operator (`,`) isn't defined by POSIX > shell specification? Hello Bagas, I do not get why you are sending this mail. The web page above has direct links to the posix specification. You can look there yourself. > Does dash support it? * Ditto. You are quoting "comma operator [...] supported [...] except dash" and still asking whether it is supported in dash. Aren't you a Debian user? Why don't you just try it out? 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'
