Bug#874305: RFS: mitlm/0.4.2-1 -- MIT Language Modeling toolkit
I've retired from sponsoring. Sorry! -- Jakub Wilk
Bug#870204: RFS: openfst/1.6.3-1 -- weighted finite-state transducers library
* Giulio Paci <giuliop...@gmail.com>, 2017-07-31, 00:19: Dear Jakub, I am looking for a sponsor for my package "openfst". Don't count on me. Sorry! -- Jakub Wilk
Re: lintian: spelling
[Disclaimer: I'm not a native speaker of English.] * Jerome BENOIT <sphericaltrian...@rezozer.net>, 2016-10-21, 01:36: is there a list where we can deal on how correct spelling error as detected by lintian ? For the curious. In the source, there is the sentence: :param int max_no_dec: number of rounds we allow to be stuck Lintian complains about "allow to" because "allow" requires an object, and in most cases[*] this object goes between "allow" and "to". But here, "number of rounds" is the object. IOW, this line could be paraphrased as: We allow $max_no_dec rounds to be stuck. I'm not sure if there's a way to fix Lintian to avoid this kind of false positives. Maybe debian-l10n-english@ would know? [*] I've seen dozens (or maybe even hundreds) of instances of "allow(s) to" when spell-checking random software, and it's the first time I see when it's not a mistake. -- Jakub Wilk
Re: HELP: python-3to2 is marked for autoremoval from testing
Not sure why is this on -mentors when -python exists, but oh well... * Gianfranco Costamagna <costamagnagianfra...@yahoo.it>, 2016-10-18, 21:14: 838974: python-3to2: FTBFS: AssertionError: 'print(*args)\n\n' != 'print *args\n\n' Does anybody have any clue why that test is now failing? I'd put my bets on: https://hg.python.org/cpython/rev/1206c64de875 I'm also considering a Python bug here, because it seems a regression to me Nope. Have fun updating gen_printargs() or maybe map_printargs() in lib3to2/fixes/fix_print.py. I tried, but it only made my head hurt. -- Jakub Wilk
Re: [buildd] unexpected FTBFS on amd64 buildd «binet»
I can reproduce the FTBFS here. gdb says: (gdb) disas $rip,$rip+1 Dump of assembler code from 0x76948f7d to 0x76948f7e: => 0x76948f7d <THRandom_nextState+205>: pcmpeqq %xmm3,%xmm0 This is a SSE4.1 instruction, which my CPU doesn't support. BTW, please make your debian/rules honour DEB_BUILD_OPTIONS=nocheck. -- Jakub Wilk
Re: Finding the correct alignment for all architectures
* Christian Seiler <christ...@iwakd.de>, 2016-10-13, 00:20: On 10/12/2016 11:51 PM, Thomas Weber wrote: I am maintaining lcms2. In #749975, I received a patch to ensure correct alignment for doubles von MIPS. I have forwarded the patch upstream[1], but in the latest release, upstream has chosen a different way. It is now possible to configure the alignment via a preprocessor variable CMS_PTR_ALIGNMENT[2]: [...] I would like to drop the Debian-specific patch. But what value for CMS_PTR_ALIGNMENT would be good/sufficient on all arches? Use _Alignof(type), that will always be correct. :-) For example: #define POINTER_ALIGNMENT_Alignof(void *) #define DOUBLE_ALIGNMENT _Alignof(double) If you are not delighted with leading underscores, you can #include and then do s/_Alignof/alignof/. Technically, this was introduced in C11/C++11, so if you need to support really old compilers, this may be problematic, but gcc/clang have supported that for a while. (A quick test tells me that gcc and clang from Jessie already support it.) gcc in wheezy supports it too. Alternatively, you may want to use the (gcc-specific) __BIGGEST_ALIGNMENT__ macro, but that kinda wasteful. For example, on i386 it's 16, even though alignof(t) is <= 4 for most t you can think of. -- Jakub Wilk
Re: Why does dh_installdebconf not add translations?
* Andreas Tille <andr...@an3as.eu>, 2016-09-10, 07:02: Found the issue myself, sorry for the noise, Andreas. Tell us what the problem was, so that we can learn too. Remark: Enhancements / proof reading of the debconf template text are welcome as well. Due to the large data set I do not like to change the text afterwards. Please ask for a review on debian-l10n-english@. -- Jakub Wilk
Re: pacakge suffix: noSOMETHIN vs bare (or something)
* Jerome BENOIT <sphericaltrian...@rezozer.net>, 2016-09-09, 13:45: I am packaging a software of general use which can be or not built against a quite heavy library targeting a minority. I plan to provide two versions of the package: you got it, one without support of the concerned library; one with support. A suffix must be added to the packages to distinct them, my issue is which one to choose. If the library was X, it would be -nox and -x11. For the package supporting the library I plan to append the suffix -[LIBRARY SHORT NAME]. Concerning the other one, I am wondering if -bare or -pure (or something) would be a better choice than -no[LIBRARY SHORT NAME]. It depends. Please tell us which package is that, and what library is that. (And in general, anonymizing your question is counterproductive most of the time. You're literally spending your energy on making the question harder to answer...) -- Jakub Wilk
Re: FTBFS: how to test fixes
* Christian Seiler <christ...@iwakd.de>, 2016-09-05, 20:33: Also note that there are plans to make init non-Essential in the future, The future is now! init is non-essential already. You can remove it from your unstable chroot if you want to. MIPS (at least 32bit) doesn't support 64bit atomic operations intrinsically (_8 == 8 bytes) - and your software uses std::atomic (found that by grepping). However, gcc provides an emulation library called libatomic. You should link against that emulation library if present in order to use those intrinsics. You shouldn't need to care about this. This should be the compiler's job. This might result in a spurious dependency on libatomic on other platforms, but unfortunately I don't know of any way to properly pass --as-needed for just this library without libtool reordering the entire list of linker flags. :-( Not tested against libtool, but this should do the trick: -Wl,--push-state,--as-needed,-latomic,--pop-state (Since this is just one g++ argument, libtool doesn't have room to reorder much.) -- Jakub Wilk
Re: FTBFS: how to test fixes
* Muri Nicanor <m...@immerda.ch>, 2016-09-05, 19:07: so, i've got my first two FTBFS bugs (on mips and hppa)- what the recommended way of testing fixes for architectures i don't have testmachines of? Ask on porters' mailing lists (debian-hppa@, debian-mips@) for someone to test it for you. If that doesn't work, ask your sponsor to test it for you. If that doesn't work, ask here for someone to test it for you. -- Jakub Wilk
Re: New #packaging IRC channel
* Ben Finney <ben+deb...@benfinney.id.au>, 2016-09-04, 17:40: Marc Haber <mh+debian-ment...@zugschlus.de> writes: Not having been on #debian-mentors for a long time, what is the problem with helping people building local packages there, having the chance of giving them skills that can be of use in Debian proper at a later time? Since you haven't been on the channel for a long time, what is your objection to creating a ‘#packaging’ channel to take the not-for-Debian packaging chatter? I didn't read what Mark wrote as an objection, but as an honest inquiry. I'm curious to know others' opinions, too. -- Jakub Wilk
Re: Built-Using:
* Paul Wise <p...@debian.org>, 2016-09-04, 09:46: As I understand Policy, Built-Using: should mention any packages, parts of which were incorporated into binary package, including any debhelper, that insert shell snippets into maintainer scripts, flex/bison. There is some controversy about Built-Using, some say it is only for packages that embed code/data that is under copyleft licenses like the GNU GPL, not for everything. Other folks would like to use it for more things, such as static linking. Either way, putting debhelper in B-U just because it generated maintainer scripts would be something novel. Which debhelper is used to create this field The field is created manually, you can see some examples here: https://codesearch.debian.net/search?q=Built-Using Yes, and this is rather cumbersome. :-\ Related dpkg build: #689062 Also, dh_buildinfo is superseded by .buildinfo files from the reproducible builds effort s/is/will be/ -- Jakub Wilk
Re: Building package locally for different architectures
[Disclaimer: I don't know anything about reprepro.]
* Dmitry Bogatov <kact...@gnu.org>, 2016-08-30, 17:38:
$ dpkg-source -b . # fine
$ debsign -m kact...@gnu.org ../*.dsc # fine
$ sbuild -d pure -c jessie # fine
$ debsign --no-re-sign ../*.changes # fine, signed with my key
$ dput local ../*.changes # fine, local -> my reprepro instance
$ rm ../*.changes # time to prepare for i386
$ sbuild -d pure -c jessie --build i386 --arch i386 # fine
You don't need "--build i386" here.
$ debsign --no-re-sign ../*.changes # fine
$ dput local ../*.changes
File "pool/main/s/sudo/sudo_1.8.10p3-1+deb8u3pure1.dsc" is already
registered with different checksums!
md5 expected: 6844ffcf32db1c64eb4106161d0d3551, got:
c75e41a14c4c2d860b6d715f22aa9f58
Is your sbuild configured to build source package by default
("$build_source = 1" in /etc/sbuild/sbuild.conf)?
If yes, I guess you'll need to turn it off (--no-source) for the second
build.
--
Jakub Wilk
Bug#835975: RFS: triops/9.0-1 [ITP]
Control: tags -1 + moreinfo * Roberto S. Galende <roberto.s.gale...@gmail.com>, 2016-08-29, 18:58: https://mentors.debian.net/debian/pool/main/t/triops/triops_9.0-1.dsc I had only a quick look at the package, but code like this: // needed by createIV_v3 srand((unsigned) time(NULL)); and iv->rand1=rand()*rand(); makes me think this is very immature and not suitable for Debian at this time. Please: 1) Document the exact algorithm and file format you use. 2) Have the design and the code reviewed by a cryptography expert. 3) Write a comprehensive test suite. 4) Gain a significant user-base. Then you can think about getting your software into Debian. -- Jakub Wilk
Bug#828978: RFS: install-mimic/0.2.0-1 (ITP)
[I don't intend to sponsor this package. Sorry!] * Sean Whitton <spwhit...@spwhitton.name>, 2016-08-27, 10:48: 1. This package has a perl and a C version of the program, and you install the C one. Have you considered installing both and using the alternatives system to permit the user to choose? Both implementation have identical functionality AFAICS, so I don't see the point of installing them both. How would the user decide which one they want? 2. Your autopkgtest test suite appears to test the perl version? Hopefully not, because it's supposed to test the install packaged, and as you noticed, there's no Perl version there... -- Jakub Wilk
Re: More C++ help needed (Was: Bug#811866: fixed in hyphy 2.2.6+dfsg-4)
* Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>, 2016-08-14, 21:39: Also, if you substitute e.g. "255*.94" for "255*94/100", make sure that you use parentheses as in "(255*94)/100", otherwise you can end up with "255*(94/100) -> 255*0 -> 0" for all such values (I cannot recall the rules now, but I think that / takes precedence over *). No, "/" and "*" (and "%") have the same precedence and left-to-right associativity. So a*b/c is equivalent to (a*b)/c. -- Jakub Wilk
Bug#834288: RFS: dblatex/0.3.8-1
* Sean Whitton <spwhit...@spwhitton.name>, 2016-08-14, 11:35: * Actualize debian/watch. Do you mean that you added a debian/watch file in this version, that was previously not present? In many European languages, including German[0], "actualize" has a false friend that means "update". I guess that's what Andreas wanted to say. :) [0] https://en.wiktionary.org/wiki/aktualisieren#German -- Jakub Wilk
Bug#827895: RFS: lua-torch-nn/0~20160604-gd23a8f5+dfsg-1 [ITP]
* Lumin <cdlumin...@gmail.com>, 2016-08-13, 16:24: X: lua-torch-nn: package-contains-no-arch-dependent-files [...] Apart from that I'm curious about how you find this issue, since I run $ lintian -i -I --pedantic xxx.changes but it didn't report such a problem. "X" stands for experimental. Use -E or --display-experimental to enable experimental tags. -- Jakub Wilk
Bug#834078: RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper
* Sean Whitton <spwhit...@spwhitton.name>, 2016-08-11, 12:07: * Update 0001-fix-unit-tests.patch for newer sbuild (Closes: #832851). The LANG environment variable might not be set. Both the original and the new patch look wrong to me: * C is not the only locale in which the test fails. * You can't determine the current locale just by looking at the LANG variable. (It can by overridden by various LC_* variables.) Ideally the test should be fixed upstream[0], but until then it's probably best to drop this half-baked patch, and instead force UTF-8 locale in debian/rules (export LC_ALL=C.UTF-8). [0] https://github.com/neithere/argh/issues/85 -- Jakub Wilk
Re: Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'
* Andreas Tille <andr...@an3as.eu>, 2016-08-10, 09:54: I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function call should be fine - so probably the problem is somewhere else - but where? https://github.com/cython/cython/issues/551 -- Jakub Wilk
Re: How do you delete a sbuild an sbuild chroot and start over?
* Jakub Wilk <jw...@debian.org>, 2016-08-05, 22:07: * Wookey <woo...@wookware.org>, 2016-08-05, 20:56: I think there is a way to stop it putting i the <> substitutions, but I can't find that now. In /etc/sbuild/sbuild.conf set: $log_filter = 0; You can also use this tool to (hopefully) reverse filtering: https://github.com/jwilk/deb-toolbox/blob/master/unfudge-build-log -- Jakub Wilk
Re: How do you delete a sbuild an sbuild chroot and start over?
* Wookey <woo...@wookware.org>, 2016-08-05, 20:56: I think there is a way to stop it putting i the <> substitutions, but I can't find that now. In /etc/sbuild/sbuild.conf set: $log_filter = 0; (It's beyond me why this is enabled by default.) -- Jakub Wilk
Bug#833459: RFS: primesieve/5.7.0+ds-1 -- fast prime number generator C/C++ library
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-08-04, 16:36: 1) X: primesieve source: maybe-not-arch-all-binnmuable libprimesieve7-dev -> libprimesieve7-dev-common probably not fixable, but I wanted to make you aware The description specially ask NOT to attempt to "fix" this. I see that this tag draws too much attention, so the next version of Lintian will not emit it (unless you figure out how to re-enable it). But wait... Why -dev and -dev-common are separate packages in the first place? They are both tiny. 2) libprimesieve7-dev versioned dev libraries makes me sad, really sad. SONAME bump was an excellent opportunity to fix this. Now that you sponsored the package, you can only blame yourself for the sadness. :> -- Jakub Wilk
Re: Preliminary questions for sponsoring a compiler
* Paul Wise <p...@debian.org>, 2016-07-30, 15:16: I myself use Alioth, Savannah, SourceForge, GitHub and LaunchPad for different projects. There are no hosting facilities that I personally like, mostly because they are all web services. There are many command-line tools that let you distance yourself from the webby nature of GitHub. This is what I use: cligh git-hub github-backup grip https://github.com/c4milo/github-release https://github.com/jwilk/github-editmeta -- Jakub Wilk
Re: Request for access to porterbox
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-28, 18:39: Subject: DebianRT Missing space between "Debian" and "RT". Also, neither the subject nor the body say what you are actually asking for... This is an OpenPGP/MIME signed message (RFC 4880 and 3156) "Requests need to be clear-signed. Request-tracker munges PGP/MIME. Also, the signed DMUP agreement needs to be clear-signed." -- Jakub Wilk
Re: weird dependency-installbility problem of buildd
* Lumin <cdlumin...@gmail.com>, 2016-07-28, 12:06: Package caffe-contrib_1.0.0~rc3-2 [1][2] build-deps on CUDA 7.5.18, which is currently available for sid. This package passed the debomatic-amd64 build [3], however when buildd is working on this package it says there is "dependency installbility problem" [4]. But how can the existing "nvidia-cuda-toolkit_7.5.18-2" (sid/non-free)[5] be missing? Does anyone know what happened there? Is this a bug? Auto-building packages with non-free build-dependencies is not supported at this time: #690282 -- Jakub Wilk
Re: Request for access to porterbox
* Christian Seiler <christ...@iwakd.de>, 2016-07-28, 11:00: As debootstrap uses regular apt rather than aptitude, why would this be a concern? For debootstrap? No. For pbuilder? Yes. Time to upgrade to sbuild? :-P -- Jakub Wilk
Re: Request for access to porterbox
* Dmitry Bogatov <kact...@gnu.org>, 2016-07-27, 22:04: Clear-signed information, required by DSA team is attached. [...] Architectures requested: hurd, m68k, sh4 FWIW, the are currently no DSA-operated porterboxes for any of these architectures. Is it true? According to https://db.debian.org/machines.cgi there is hurd and sh4 porterboxes. Hurd porterbox does exist, but it's not operated by DSA. I couldn't connect to any of the listed sh4 porterbox, but they're not operated by DSA either. Rationaly: reproduce #832544, #832543 Have you asked on porters' mailing lists for help? I found neither m68k nor sh4 lists debian-68k@ debian-superh@ -- Jakub Wilk
Re: Request for access to porterbox
* Dmitry Bogatov <kact...@gnu.org>, 2016-07-27, 20:41: Clear-signed information, required by DSA team is attached. [...] Architectures requested: hurd, m68k, sh4 FWIW, the are currently no DSA-operated porterboxes for any of these architectures. Rationaly: reproduce #832544, #832543 Have you asked on porters' mailing lists for help? -- Jakub Wilk
Bug#832246: RFS: cligh/0.2-5
* Dmitry Bogatov <kact...@gnu.org>, 2016-07-23, 16:36:
http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-5.dsc
Have you forwarded fix-format-string.patch and
fix-repo-detection.patch upstream?
Yes. Upstream applied, but no new release was created.
Please consider adding Forwarded field to patch headers.
But this part of fix-format-string.patch:
- die("""%s is not a valid issue number.""")
+ die("""%s is not a valid issue number.""" % args.number)
doesn't look fixed in upstream VCS.
--
Jakub Wilk
Bug#832246: RFS: cligh/0.2-5
[I don't intend to sponsor this package. Sorry!] * Dmitry Bogatov <kact...@gnu.org>, 2016-07-23, 08:46: http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-5.dsc Have you forwarded fix-format-string.patch and fix-repo-detection.patch upstream? Changes since last upload: * Change section to 'utils' Hmm, why? I'd expect it to be in section "vcs". Either way, I don't think just changing package section warrants a new upload. -- Jakub Wilk
Re: Dealing with "duplicate-font-file" lintian warning
* Tiago Ilieve <tiago.my...@gmail.com>, 2016-07-22, 15:49: W: grip: duplicate-font-file usr/share/grip/grip/static/octicons/octicons.ttf also in fonts-octicons Is there a helper to deal with this kind of issue? Like the "sphinxdoc"[2] one, which automatically replaces embedded JS files to their respective links? dh_sphinxdoc is a tool to post-process documentation generated by Sphinx at build time. It is necessary, because the set of files you should symlink varies with Sphinx version. But in this case, the files come directly from upstream tarball, so there's no need for a dedicated tool. Just use dh_link. -- Jakub Wilk
Re: reproducible-builds
* Dominique Dumont <d...@debian.org>, 2016-07-19, 11:29: dvbackup Is this package worth the effort ? Is there anyone left who use DV tapes to perform backups when a 16GB thumb drive has more capacity and is more practical for this purpose than a DV camcorder ? I certainly wouldn't recommend dvbackup for making new backup. It might be still useful for restoring existing backups. -- Jakub Wilk
Re: Bug#831694: RFS: shadowsocks-libev/2.4.7+20160630+ds-3 -- lightweight and secure socks5 proxy
* Christian Seiler <christ...@iwakd.de>, 2016-07-18, 17:21: I'm not a DD, Sounds like a bug to me! -- Jakub Wilk
Re: Help with shlibs system
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-18, 11:53: Symbols files are usually better since you get more fine grained control of dependencies, but they take a lot more time to maintain (especially for C++ libraries). In this very specific case, I think we don't need it, as I explained here [1] and you can see how upstream is taking seriously the ABI now [2] I don't see what upstream dedication to ABI compatibility has to to with symbol files. Anyway, the reason we're having this thread is because apparently libjsoncpp broke ABI without SONAME change, so maybe they're not taking it seriously enough. :> -- Jakub Wilk
Re: Secure Vcs-Git on alioth
* Yuri D'Elia <wav...@thregr.org>, 2016-07-17, 14:15: Regarding Lintian's informational warning about insecure git:// URIs in the Vcs-Git field: https://lintian.debian.org/tags/vcs-field-uses-insecure-uri.html I can switch easily from: git://anonscm.debian.org/collab-maint/trend.git to https://anonscm.debian.org/git/collab-maint/trend.git however shallow cloning (which I use regularly), breaks. Are you sure it's about git:// vs https://? Shallow cloning has never worked for me reliably: $ git clone -v --depth=10 git://anonscm.debian.org/collab-maint/trend.git Cloning into 'trend'... Looking up anonscm.debian.org ... done. Connecting to anonscm.debian.org (port 9418) ... 5.153.231.21 done. fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed $ git clone -v --depth=10 https://anonscm.debian.org/git/collab-maint/trend.git Cloning into 'trend'... POST git-upload-pack (156 bytes) POST git-upload-pack (165 bytes) fatal: The remote end hung up unexpectedly fatal: protocol error: bad pack header -- Jakub Wilk
Re: Secure URI replacement for svn://anonscm.debian.org ?
* Thomas Schmitt <scdbac...@gmx.net>, 2016-07-16, 15:38: lintian.debian.org accuses package libburn of [I] vcs-field-uses-insecure-uri vcs-browser http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/ vcs-svn svn://anonscm.debian.org/pkg-libburnia/trunk/libburn/ The first URI can simply be changed to https:, but the svn: URI makes me riddle. I think Lintian is trying to tell you in veiled way that you should use a better VCS. :-P I don't believe that Alioth's supports HTTPS for Subversion at the moment. :-( -- Jakub Wilk
Re: Call for review: Improving RFS template for mentors.debian.net
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-14, 22:06: Typo: an QA upload -> an QA upload I fail to see differences... did you mean "a QA upload"? Oops. I meant: an QA upload -> a QA upload -- Jakub Wilk
Re: Call for review: Improving RFS template for mentors.debian.net
* HAYASHI Kentaro <ken...@gmail.com>, 2016-07-11, 23:07: Collect 'QA upload.' information by debianqa plugin https://github.com/debexpo/debexpo/pull/42 [...] As you suggested, it is simple to check Maintainer field. I got it. Thank you for feedback! Typo: an QA upload -> an QA upload You can find misspellings like this using anorack: http://jwilk.net/software/anorack -- Jakub Wilk
Re: libgdbm transition
* Tobias Frost <t...@debian.org>, 2016-07-13, 21:17: You will have to file all the bugs manually, but I expect all the bugs will follow a similar template. You'll find mass-bug(1) from devscripts helpful on the filing part. Unlikely. mass-bug(1) produces almost series of almost-identical mails that can vary only with package name and version. That's not enough to produce useful FTBFS bug reports. Also, #556375 disqualifies mass-bug(1) as a serious tool for me. -- Jakub Wilk
Bug#830569: RFS: z3/4.4.1-0.1 [NMU] [4xRC]
Any reason why your .orig.tar is different than the one uscan downloads?
$ md5sum z3_4.4.1.orig.tar.gz*
94e21f86056f986c320653912be53f8a z3_4.4.1.orig.tar.gz
4336a9df24f090e711c6d42fd4e2b1fc z3_4.4.1.orig.tar.gz.github
* Fabian Wolff <fabi.wo...@arcor.de>, 2016-07-10, 00:56:
* Install shared libraries into new libz3-4 package (Closes: #819884).
Now that the -dev package doesn't ship any ELFs, you should remove
${shlib:Depends} from -dev's Depends.
"Pre-Depends: ${misc:Pre-Depends}" should be moved to the shared
library package, or removed completely, because it's not needed these
days.
I removed it, but does it do any harm?
They didn't have any effect on the binary package. They were just
misleading.
These d/rules lines are effectively no-ops and should be removed:
mkdir -p debian/tmp/usr/lib/python2.7/dist-packages/z3
touch debian/tmp/usr/lib/python2.7/dist-packages/z3/__init__.py
(The latter is probably a failed attempt of fixing #791604, which
looks like a previous incarnation #819884.)
True, I fixed it. The first mkdir is necessary, though, to make the
directory debian/tmp/usr/lib/python2.7/dist-packages/. dh_auto_install
fails otherwise.
It would be cool to fix the upstream build system, so that it creates
dist-packages when it's missing.
* Disable tests as they fail eventually.
All the tests? :-O
It's more like one big one that calls individual functions that test
something. Most of the tests passed, but after about 1 GB (!) of test
output had been written on screen, something segfaulted. This is one of
those issues that probably need further investigation,
To be frank, I don't thin disabling whole testsuite is a good plan,
especially for an NMU. The package might mostly work for you, but maybe
it'll be completely broken when compiled on another architecture or with
a different compiler version. We do want to notice when this happens.
I've tried building z3 with hardening flags turned on, but the build
failed.
What was the error message?
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
Makefile:3867: recipe for target 'libz3.so' failed
Might have something to do with -fPIE vs. -fPIC,
Right. Many build systems don't tolerate -fPIE/-pie out of the box. This
is explained in the dpkg-buildflags manpage, with hints how to fix it:
“Unconditionally passing -fPIE, -fpie or -pie to a build‐system using
libtool is safe as these flags will get stripped when building shared
libraries. Otherwise on projects that build both programs and shared
libraries you might need to make sure that when building the shared
libraries -fPIC is always passed last (so that it overrides any previous
-PIE) to compilation flags such as CFLAGS, and -shared is passed last
(so that it overrides any previous -pie) to linking flags such as
LDFLAGS.”
This is definitely not a regression, though,
That's right.
--
Jakub Wilk
Re: Please help porting cufflinks to latest libboost
* Andreas Tille <andr...@an3as.eu>, 2016-07-12, 11:12: In file included from /usr/include/eigen3/Eigen/Core:297:0, from /usr/include/eigen3/Eigen/Dense:1, from abundances.h:21, from abundances.cpp:16: /usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h: In instantiation of 'Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType Eigen::DenseCoeffsBase<Derived, 0>::coeff(Eigen::Index) const [with Derived = Eigen /usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:181:19: required from 'Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType Eigen::DenseCoeffsBase<Derived, 0>::operator()(Eigen::Index) const [with Derived abundances.cpp:3815:28: required from here /usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:141:7: error: 'THIS_COEFFICIENT_ACCESSOR_TAKING_ONE_ACCESS_IS_ONLY_FOR_EXPRESSIONS_ALLOWING_LINEAR_ACCESS' is not a member of 'Eigen::internal::static_assert EIGEN_STATIC_ASSERT(internal::evaluator::Flags & LinearAccessBit, ^ Makefile:1627: recipe for target 'abundances.o' failed The relevant code in src/abundances.cpp looks like this: Eigen::VectorXd v; double m = 0; v = U.rowwise().sum(); m = v.colwise().sum()(0); For some reason Eigen thinks that v.colwise().sum() cannot be treated as a one-dimensional vector, which smells like a bug in Eigen. Changing the last line to m = v.colwise().sum()(0, 0); seems to do the trick. Upstream bug report: https://github.com/cole-trapnell-lab/cufflinks/issues/61 -- Jakub Wilk
Bug#829151: RFS: setcolortemperature/1.1-1 ITP
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-11, 17:13: are you sure it is 6500K? 6500K should be equal to "650" K == Kelvin, not kilo. -- Jakub Wilk
Re: Call for review: Improving RFS template for mentors.debian.net
* HAYASHI Kentaro <ken...@gmail.com>, 2016-07-10, 06:13: Collect 'QA upload.' information by debianqa plugin https://github.com/debexpo/debexpo/pull/42 Um, that's... unusual way to search for a string. Have you tried using regular expressions? :) Or alternatively, it might be simpler to look at the Maintainer field. The e-mail address should be packa...@qa.debian.org for all QA uploads. P.S. Does anyone knows the way to check [RC] case easily - the package contains fixed RC bugs debexpo already knows about bugs the upload would close and their severities. For example https://mentors.debian.net/package/aspell-sk reads: | Package closes bugs | |aspell-sk: |#603719 (normal): Please update package aspell-sk |src:aspell-sk: |#817360 (serious): aspell-sk: Removal of debhelper compat 4 -- Jakub Wilk
Bug#830569: RFS: z3/4.4.1-0.1 [NMU] [4xRC]
Control: tags -1 + moreinfo * Jakub Wilk <jw...@debian.org>, 2016-07-09, 20:33: Yes, it does look like a bug in Lintian. Apparently it gets confused by the -ocaml-dev package: $ lintian libz3-4_4.4.1-0.1_amd64.deb libz3-dev_4.4.1-0.1_amd64.deb [nothing] $ lintian libz3-4_4.4.1-0.1_amd64.deb libz3-dev_4.4.1-0.1_amd64.deb libz3-ocaml-dev_4.4.1-0.1_amd64.deb W: libz3-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libz3.so.4 usr/lib/x86_64-linux-gnu/libz3.so Actually, the culprit is that libz3-dev must depend libz3-4, but it doesn't. (OTOH, libz3-ocaml-dev does depend on libz3-4, which tricked Lintian into thinking this is where the .so symlink should be.) -- Jakub Wilk
Re: Call for review: Improving RFS template for mentors.debian.net
* HAYASHI Kentaro <ken...@gmail.com>, 2016-07-10, 00:00: This PR is written to solve some glitches about RFS template. another feature request: the template has also the subject, e.g. ITP, NMU, RC, QA, and so on, but there seems to be one missing entry for "regular update" Thank you for feedback. But I hadn't ever seen such tag. https://mentors.debian.net/sponsor/rfs-howto There's no standard tag for this, and I don't think we need one. If there's no tag in the subject, then the upload is supposed to be "regular". -- Jakub Wilk
Re: Example of combined manpage with symlinks to multiple binaries?
* Patrick Schleizer <patrick-mailingli...@whonix.org>, 2016-07-09, 20:36: Do you know any example of a combined manpage? grep, egrep, fgrep, rgrep gzip, gunzip, zcat, uncompress -- Jakub Wilk
Bug#830569: RFS: z3/4.4.1-0.1 [NMU] [4xRC]
Hi Fabian!
I don't intend to sponsor this upload, but here's a quick review:
* Fabian Wolff <fabi.wo...@arcor.de>, 2016-07-09, 16:14:
* Add patch fix-dotnet-version.patch (Closes: #808695).
This gives me no clue what the patch is about.
* Upgrade to Standards version 3.9.8 (no changes).
I don't think this is a good idea for an NMU.
* Install shared libraries into new libz3-4 package (Closes: #819884).
Now that the -dev package doesn't ship any ELFs, you should remove
${shlib:Depends} from -dev's Depends.
"Pre-Depends: ${misc:Pre-Depends}" should be moved to the shared library
package, or removed completely, because it's not needed these days.
* Install python files directly into /usr/lib/python2.7/dist-packages/
AFAICS, upstream build system installs these files in the right place,
so there should be no need to pick the *.py files from src/.
These d/rules lines are effectively no-ops and should be removed:
mkdir -p debian/tmp/usr/lib/python2.7/dist-packages/z3
touch debian/tmp/usr/lib/python2.7/dist-packages/z3/__init__.py
(The latter is probably a failed attempt of fixing #791604, which looks
like a previous incarnation #819884.)
* Remove unnecessary version restriction of build dependency
cli-common-dev.
Hmm, I don't know anything about CLI, but dh_cligacpolicy disagrees:
dh_cligacpolicy: Warning! No Build-Depends(-Indep) on cli-common-dev (>= 0.5.7)!
* Format debian/control with cme.
I don't think cosmetic changes are good idea for an NMU.
* Disable tests as they fail eventually.
All the tests? :-O
I've tried building z3 with hardening flags turned on, but the build
failed.
What was the error message?
I don't know what the problem with the -dev package is; contrary to
what Lintian claims, it *does* contain a symlink to the respective
shared library.
Yes, it does look like a bug in Lintian. Apparently it gets confused by
the -ocaml-dev package:
$ lintian libz3-4_4.4.1-0.1_amd64.deb libz3-dev_4.4.1-0.1_amd64.deb
[nothing]
$ lintian libz3-4_4.4.1-0.1_amd64.deb libz3-dev_4.4.1-0.1_amd64.deb
libz3-ocaml-dev_4.4.1-0.1_amd64.deb
W: libz3-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libz3.so.4
usr/lib/x86_64-linux-gnu/libz3.so
W: libz3-ocaml-dev: hardening-no-relro usr/lib/ocaml/z3/dllz3ml.so
There are a few other issues that I was not able to fix, but I think
closing the four RC bugs has a higher priority right now.
Absolutely. It's not NMUer obligation to fix every known bug.
--
Jakub Wilk
Re: combined manpage with symlinks to multiple binaries across packages: how to do?
* Andrew Shadura <and...@shadura.me>, 2016-07-09, 00:20: I get a plain text file installed that just contains .so isns_config.5 Which man doesn't really interpret itself, and which is hence completely useless. That's strange, as normally man would interpret that, and it actually worked for me. Yeah, it should work: # echo '.so nyancat.1' | gzip -9n > /usr/share/man/man1/foo.1.gz # man foo | head -n1 NYANCAT(1) General Commands Manual NYANCAT(1) -- Jakub Wilk
Re: combined manpage with symlinks to multiple binaries permissible?
* Patrick Schleizer <patrick-mailingli...@whonix.org>, 2016-07-08, 14:18: Would a combined manpage, i.e. 'man corridor', symlinked to the individual command names (corridor-init-forwarding, corridor-init-snat, ...) be acceptable by Debian policy Yes, this is fine. -- Jakub Wilk
Re: Call for review: Improving RFS template for mentors.debian.net
* HAYASHI Kentaro <ken...@gmail.com>, 2016-07-08, 18:28: https://github.com/debexpo/debexpo/pull/35 Not a regression, but instead of: "upstreams web site" it should be: "upstream's web site" or maybe: "upstream web site" Perhaps also s/web site/website/. -- Jakub Wilk
Re: wrong version number ?
* Herbert Fortes <h...@ig.com.br>, 2016-07-07, 15:30: I am doing a QA for dvbackup package. I do not need a Sponsor. debian/changelog: dvbackup (1:0.0.4-8) unstable; urgency=low ( I am doing ) dvbackup (1:0.0.4-7) unstable; urgency=low ( current version ) After 'debuild': dvbackup_0.0.4-8_amd64.deb ( no epoch ) Related bug: #645895. -- Jakub Wilk
Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-06, 10:27: As per Developer's Reference §5.11.1 this should have been uploaded to DELAYED/10 at least. Also, the NMU diff should be sent to BTS before the package is uploaded. In general you are right, but in this case upstream and Debian maintainers seems to be the same people, and they acked the other NMUs in a matter of minutes. https://github.com/Yubico/libu2f-host-dpkg/issues/2 they were aware of the ongoing NMU since 9 days, and this is the 3th NMU that goes in unstable. No, ACKing a NMU is not a blanket permission to do further further NMUs. And if the maintainers were actually happy with any NMUs whatsoever, then they could put the package on the lowNMU list, or orphan the package. (The latter would be more honest IMO.) -- Jakub Wilk
Bug#829605: RFS: aspell-sk/2.02-0-0.1 [RC, NMU]
* Pali Rohár <pali.ro...@gmail.com>, 2016-07-05, 14:28: debian/copyright says that the package "was downloaded from ftp://ftp.gnu.org/gnu/aspell/dict/sk/;, but there is no 2.02-0 at this location. I mentioned this because it's a serious violation of Policy §12.5: “the copyright file must say where the upstream sources (if any) were obtained”. Official website for aspell-sk is http://www.sk-spell.sk.cx/aspell-sk where is also last version. On gnu.org is not last version and upstream maintainer confirmed it. Then please update the copyright file. BTW, what's the difference between 2.01-2 and 2.02-0? There's no entry for the latter version in doc/CHANGELOG. :-\ There is small changelog entry at website, that dictionary was updated to Firefox/Thunderbird version. Quick look at diff between those two versions confirm it. Dictionary is updated (new words + some fixes). OK. Please remind upstream that they should keep their changelog up to date. :) Also, the copyright file says that the package is under GPL, whereas this new version is tri-licensed: LGPLv2.1, GPLv2, MPLv1.1. Ok, I can update debian/copyright file. Please do. * Add Homepage and update Standards-Version. Why are these two in a single item? They seem unrelated to me. Those were changes in (one) control file, so I added them to one line. Did you need to do any packaging changes to update S-V? I wouldn't recommend updating S-V in an NMU. Well, Debian has in archives very old (maybe prehistoric) version of aspell-sk package. I reported this problem in bug 603719 in past *six* years ago and everybody in Debian ignored it, current maintainer too. And now when I saw that aspell-sk package is going to be removed from Debian, I updated compat level and thought that bringing new version should be done too... There are over 150 different things that changed in Policy since 3.6.2. I don't feel like going through all of them to verify that the package does in fact meet all the new requirements. I'm also surprised that any NMUer would want to go trough this effort, instead of letting the maintainer do it later.[*] Addition of debian/watch is not documented in the changelog. I can add it. Please do. You changed source format to "3.0 (quilt)", but this change is not documented either. Also, changing source format is not suitable for an NMU, unless you have a very good reason. I thought that "3.0 (quilt)" format is preferred for new packages, It's not a new package. :) And I don't know what are the maintainer's preferences.[*] [*] In general, please keep NMUs lean. Fix the bugs that bother you; leave everything else as is. -- Jakub Wilk
Re: symbols file handling Was: Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-07-06, 08:36: - u2fh_check_version@U2F_HOST_0.0 0.0 + u2fh_check_version@U2F_HOST_0.0 1.0 The changelog for this package didn't help me understand what's going on, so I'll answer in general: A change like this does look suspicious, but it's not necessarily an error. 1) It could be because the function changed in such a way that old programs continue to work, but it enabled a feature newly compiled code may take advantage of. 2) Or it could be because the symbol, contrary to its name, was actually introduced in version 1.0, that is, the original symbols file was erroneous. what does this mean? do reverse-dependencies needs a rebuild then? In the second case, some rev-deps might need to be rebuilt to correct their Depends. -- Jakub Wilk
Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor
The full changelog was: * Non-maintainer upload. * New upstream version 1.1.2 (2016-06-22) * Use compile-time hardening * Use HTTPS for Vcs-Git * Update and fix the symbols file. * Fix the copyright file. On Tue, Jul 05, 2016 at 01:59:59PM +0200, Nicolas Braud-Santoni wrote: The proper maintainer of the package seems unresponsive, and 2 RC bugs (FTBFS) were previously fixed by codehelp and myself after sitting without acknowledgment for a month. Seems irrelevant to this bug... * Adam Borowski <kilob...@angband.pl>, 2016-07-06, 02:05: Appears to be good, uploaded. As per Developer's Reference §5.11.1 this should have been uploaded to DELAYED/10 at least. -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer <jre.wine...@gmail.com>, 2016-07-05, 21:24: First off, many thanks again for that script. Unfortunately it fails in Ubuntu (see #827770): ./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3 libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.8 libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8 libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1 libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libxslt.so.1 libXxf86vm.so.1 > debian/tmp/elf.recommends /usr/bin/ld: cannot find libGL.so.1 collect2: error: ld returned 1 exit status debian/rules:153: recipe for target 'override_dh_shlibdeps' failed In Ubuntu libGL.so.1 is in /usr/lib//mesa/. Ugh. :-\ This is not a problem for normally linking with -lGL because the libGL.so symlink lives directly in /usr/lib//. It's also not a problem at runtime, because /usr/lib//mesa/ is included in /etc/ld.so.conf.d/_GL.conf. But it does break sonames2elf, because ld(1) doesn't pay attention to /etc/ld.so.conf*. As a work-around, changing "libGL.so.1" to "libGL.so" in the sonames2elf command-line seems to do the trick. (You may want to implement extra check to ensure that the linker found exactly the same SONAME as it should.) -- Jakub Wilk
Re: Weird unmet build dependencies on buildds
* Ole Streicher <oleb...@debian.org>, 2016-07-05, 21:26: Dependency installability problem for dpuser on i386: dpuser build-depends on: - i386:libvtk6-dev i386:libvtk6-dev depends on: - i386:python-vtk6 (= 6.3.0+dfsg1-1) i386:python-vtk6 depends on: - i386:python-twisted i386:python-twisted depends on: - i386:python-twisted-core (>= 16.2.0-1) i386:python-twisted-core depends on: - i386:python-openssl i386:python-openssl depends on: - i386:python-cryptography (>= 1.3) i386:python-cryptography depends on missing: - i386:python-cffi-backend-api-min (<= 9729) At the moment wanna-build doesn't grok versioned provides. See debian-wb-team@ldo archives for details. -- Jakub Wilk
Bug#829605: RFS: aspell-sk/2.02-0-0.1 [RC, NMU]
Control: owner -1 ! Control: tags -1 + moreinfo * Pali Rohár <pali.ro...@gmail.com>, 2016-07-04, 18:13: dget -x https://mentors.debian.net/debian/pool/main/a/aspell-sk/aspell-sk_2.02-0-0.1.dsc Changes since the last upload: * Non-maintainer upload. * New upstream release (Closes: #603719). debian/copyright says that the package "was downloaded from ftp://ftp.gnu.org/gnu/aspell/dict/sk/;, but there is no 2.02-0 at this location. BTW, what's the difference between 2.01-2 and 2.02-0? There's no entry for the latter version in doc/CHANGELOG. :-\ Also, the copyright file says that the package is under GPL, whereas this new version is tri-licensed: LGPLv2.1, GPLv2, MPLv1.1. * Use compat level 9 (Closes: #817360). Did you need to do any packaging changes to bump compat? * Add Homepage and update Standards-Version. Why are these two in a single item? They seem unrelated to me. Did you need to do any packaging changes to update S-V? I wouldn't recommend updating S-V in an NMU. Addition of debian/watch is not documented in the changelog. You changed source format to "3.0 (quilt)", but this change is not documented either. Also, changing source format is not suitable for an NMU, unless you have a very good reason. -- Jakub Wilk
Re: pause command line utility
* Dmitry Bogatov <kact...@gnu.org>, 2016-07-02, 03:45:
#include
int main (void)
{
return pause();
}
Is there any standard utility for it?
$ perl -MPOSIX -e pause
--
Jakub Wilk
Bug#827907: RFS: evil/1.2.12-1 ITP
* Sean Whitton <spwhit...@spwhitton.name>, 2016-07-01, 08:13: I would be grateful, Jakub, if you could try the build on your sbuild config before I file a bug against sbuild suggesting this be the default. The repo, for your convenience: https://anonscm.debian.org/git/pkg-emacsen/pkg/evil-el Why .orig.tar from pristine-tar is different than the on uscan downloads? I tried to build the package in sbuild in a (clean but not quite up-to-date) VM, and it indeed FTBFS: dtach -n debian/elpa-test.sock sh -c '/usr/bin/make test && touch debian/elpa-test.ok' dtach: Could not find a pty. debian/rules:21: recipe for target 'override_dh_elpa_test' failed I don't understand why, though. /dev/pts is mounted in the chroot, as it should... -- Jakub Wilk
Bug#827907: RFS: evil/1.2.12-1 ITP
* Sean Whitton <spwhit...@spwhitton.name>, 2016-06-30, 13:32: override_dh_elpa_test: dtach --foo --bar -- dh_elpa_test It's probably not _that_ simple. dtach, understandably, ignores exit status of the program it runs. I think you'll need something like this: override_dh_elpa_test: rm -f test_exit_status dtach -c tmpsocket sh -c 'dh_elpa_test; echo $$? > test_exit_status' rc=$$(cat test_exit_status) && exit $rc -- Jakub Wilk
Bug#829012: RFS: udftools/1.2-0.1 [NMU] [RC]
I don't intend to sponsor this package, but... * Pali Rohár <pali.ro...@gmail.com>, 2016-06-29, 21:01: * New upstream release: Closes: #672839, #272648, #606664, #715720, #716102, #716287, #727634 Closes: #727636, #775273, #539530, #680272 ...this looks as if there were 11 different bugs asking to package new upstream release. -- Jakub Wilk
Re: Bug#827907: RFS: evil/1.2.12-1 ITP
* Elena ``of Valhalla'' <elena.valha...@gmail.com>, 2016-06-29, 10:13: 2. In d/copyright, I think you need to specify copyright years for the copyright holders. Just their names is not enough, since on a desert island ~60 years from now with no newer versions of evil available for download, the code would become public domain :) (well, I guess the old version of the code would be public domain on the mainland too) AFAIK as long as the copyrigth date is recent enough (i.e. it doesn't end in one of the miriad exceptions for past works) and the copyright holder is not anonymous/a company the date of publication isn't relevant for copyright expiry, just the date of death of the author (which of course is not known in advance, so people on a desert island have no way to know for sure whether something is in public domain because of copyright expiry). The legislators of the desert island were fully aware it's difficult to establish dates of most creators' deaths. That's why they changed the island's copyright law to only take publication dates into account. -- Jakub Wilk
Bug#827907: RFS: evil/1.2.12-1 ITP
* Dmitry Bogatov <kact...@gnu.org>, 2016-06-27, 17:32: Mercurial upstream repository, and tarballs are named not after version, but after hashes. I fail to extract anything useful from this page: [1] [1] https://bitbucket.org/lyro/evil/downloads This seems to work for me: version=3 https://bitbucket.org/lyro/evil/downloads .*/get/([0-9.]+)[.]tar[.]gz -- Jakub Wilk
Re: Help needed for autoreconf hmmer
* Andreas Tille <andr...@an3as.eu>, 2016-06-27, 12:41: dh_autoreconf autoheader: warning: missing template: EASEL_COPYRIGHT autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description]) Normally one would fix such errors by adding third argument (description) to all instanced of AC_DEFINE(_UNQUOTED) where it was missing. But in this case upstream doesn't seem to be using autoheader at all; their header template (easel/esl_config.h.in) looks manually-crafted. So you should probably just ask autoreconf not to call autoheader: AUTOHEADER=true dh_autoreconf -- Jakub Wilk
Bug#827982: RFS: libstroke/0.5.1-7 [QA, RC] -- mouse strokes library
* Sean Whitton <spwhit...@spwhitton.name>, 2016-06-23, 23:36: https://mentors.debian.net/debian/pool/main/libs/libstroke/libstroke_0.5.1-7.dsc Looks pretty good to me. Just a few minor points: + * Bump debhelper compat to 5 (Closes: #817554). There's still "debhelper (>= 4)" in Build-Depends. It's not a problem in practice, because debhelper (>= 5) is available even in oldoldoldoldstable, but the pedant in me is slightly bothered. + * Fix calling ldconfig trigger: Sounds odd. s/calling/generating/ maybe? +build-arch: build +build-indep: build There are no architecture-independent packages, so it would be more natural to have build-indep do nothing. But then binary-indep is not a no-op either. Meh, let's leave it as is. This debian/rules is a mess anyway. + # empties dependency_libs from .la file + # http://lists.debian.org/debian-devel/2009/08/msg00783.html + sed -i "s,^dependency_libs=.*,dependency_libs=''," $(CURDIR)/debian/libstroke0-dev/usr/lib/libstroke.la I recommend against using $(CURDIR) if possible, as it causes unnecessary noise in build logs. Here you could use a relative path. -- Jakub Wilk
Bug#827982: RFS: libstroke/0.5.1-7 [QA, RC] -- mouse strokes library
* Sean Whitton <spwhit...@spwhitton.name>, 2016-06-23, 22:22: * Replace libstroke0.postinst with ldconfig trigger in libstroke0.triggers. You shouldn't need this file; dh_makeshlibs is supposed to register the trigger automatically. It doesn't, Hmm, indeed. for some reason :) The order of dh_ commands in debian/rules is b0rked. dh_installdeb should be called after dh_makeshlibs. NB, this is detected by Lintian: W: libstroke source: debian-rules-calls-debhelper-in-odd-order dh_makeshlibs (line 74) https://mentors.debian.net/debian/pool/main/libs/libstroke/libstroke_0.5.1-7.dsc I understand that you don't want to spend too much time on polishing the package, but I'd like these Lintian warnings fixed: W: libstroke source: configure-generated-file-in-source config.log (this was introduced in -7) W: libstroke source: debian-rules-missing-recommended-target build-indep W: libstroke source: debian-rules-missing-recommended-target build-arch (this is violation of a "must" policy) W: libstroke source: debhelper-but-no-misc-depends libstroke0 W: libstroke source: debhelper-but-no-misc-depends libstroke0-dev -- Jakub Wilk
Bug#827982: RFS: libstroke/0.5.1-7 [QA, RC] -- mouse strokes library
* Sean Whitton <spwhit...@spwhitton.name>, 2016-06-23, 22:02: * Replace libstroke0.postinst with ldconfig trigger in libstroke0.triggers. You shouldn't need this file; dh_makeshlibs is supposed to register the trigger automatically. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/l/libstroke/libstroke_0.5.1-7.dsc It's 404... -- Jakub Wilk
Re: Help with python packaging
* Peter Spiess-Knafl <d...@spiessknafl.at>, 2016-06-20, 11:23: 2.) The script gets installed with the .py suffix, how can I drop this? Get it fixed upstream. -- Jakub Wilk
Bug#827333: RFS: newlisp/10.7.0-1 [ITP]
* Andrey Rahmatullin <w...@debian.org>, 2016-06-20, 00:25: W: newlisp: unusual-interpreter usr/bin/newlispdoc #!newlisp W: newlisp: unusual-interpreter usr/share/newlisp/util/syntax.cgi #!newlisp Out of these, the unusual-interpreter tags are blockers as I don't know how such shebangs could work. The Lintian output is misleading; the actual shebangs look like this: #!/usr/bin/env newlisp -- Jakub Wilk
Bug#827487: RFS: circle/2.2-1 [ITP]
I had a quick look at this package too: Vcs-Git is supposed to point to Debian packaging, not to upstream VCS. (After you fix it, please also add Vcs-Browser.) Where did the upstream tarball come from? There is no watch file, and debian/copyright points to <https://github.com/circulosmeos/circle.git>, which doesn't have a release for version 2.2. * Adam Borowski <kilob...@angband.pl>, 2016-06-18, 23:21: debian/rules: * please move flags exports before including dpkg/default.mk. The order matters -- your version doesn't use hardening. Or remove the include and DPKG_EXPORT_BUILDFLAGS, and let debhelper do the job... Also, I wonder if there's a better place for the URL than /usr/share/doc/README. (I hope this path is a typo...) The better place is the Homepage field; and in fact this very URL is already there, ... Other stuff in that file are build instructions which are irrelevant for packaged software. ...so I'd recommend not shipping README in the binary package at this time. Typo in the manpage: easy of use -> ease of use Also, "ascii" is normally spelled "ASCII". Please forward the manpage upstream. Spell-checking was brought to you by mwic: http://jwilk.net/software/mwic -- Jakub Wilk
Bug#827149: RFS: triggerhappy/0.4.0-1
Control: tags -1 + moreinfo [I don't intend to sponsor this package.] * Stefan Tomanek <stefan.tomanek+deb...@wertarbyte.de>, 2016-06-12, 23:59: https://mentors.debian.net/debian/pool/main/t/triggerhappy/triggerhappy_0.4.0-1.dsc Bumping compat to 9 is not documented in the changelog. Please double-check that all other changes are documented, too. Your copyright file says "License: GPL-3", but it's "GPLv3 or any later version" according to upstream source. Also, it's not enough to say "On Debian systems, the full text ..." in the License field. You need to actually quote the license statement, i.e. "You have permission to copy, modify, and redistribute ...". Tagging this bug moreinfo, because the update would introduce an RC bug. -- Jakub Wilk
Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
I see there's now 1.18-1 at <https://git.sur5r.net/tio/>; but upstream released 1.20 in the mean time. * Jakub Wilk <jw...@debian.org>, 2016-05-22, 14:26: I'd rather have only a single changelog entry for the initial release. This is still unfixed. export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed This seem unnecessary, given that this program doesn't link to any libraries (except implicitly to libc). Ditto. -- Jakub Wilk
Bug#827043: RFS: gdbm/1.12-1 ITP
* Gianfranco Costamagna <costamagnagianfra...@yahoo.it>, 2016-06-12, 09:54: there was a gfdl lintian pedantic warning, but seems a false positive, You are probably[0] referring to: P: gdbm source: license-problem-gfdl-non-official-text doc/gdbm.info invariant part is: with no invariant sections, no front-cover, and no back-cover texts P: gdbm source: license-problem-gfdl-non-official-text doc/gdbm.texinfo invariant part is: with no invariant sections, no front-cover, and no back-cover texts The tag name is not great, and it's debatable whether it's useful (which is why it's pedantic), but this is true positive. The tag description is: The given source file is licensed under GFDL, but using a non-official text for the "no invariant sections" part. Please ask upstream to always use (case insensitive): with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. (IMO it's a bug in Lintian that it treats the text case-insensitively, because "Invariant Sections", "Front-Cover Texts" and "Back-Cover Texts" are terms defined in the license and therefore should be spelled exactly this way. But I digress...) In the gdbm, you have: with no Invariant Sections, no Front-Cover, and no Back-Cover texts. Note missing "Texts" after "Front-Cover" and lowercase "texts" at the end. [0] Please always paste exact output of static analysis tools. This will help people diagnose the problem without the hassle of downloading packages and running the tools themselves. Also, the output may vary with the tool's version, used options, or the phase of the moon. -- Jakub Wilk
Re: phonetisaurus in unstable
* Giulio Paci <giuliop...@gmail.com>, 2016-06-08, 11:48: In #825236, Giulio asked me about uploading phonetisaurus to unstable. If I were the maintainer, I would hesitate to make such upload until the following is done: I forgot one thing: * phonetisaurus-calculateER should escape arguments before passing them to shell. Or, better, it should use the subprocess module instead of os.system(). * 1001_fix_binaries_return_values.patch is accepted upstream. (Are they alive?) They are alive (latest commit in their repository is from 3 months ago), although they have not made any proper release since a long time. Hmm, I had a look at the repo. "!WARNING: In Flux!"[0] and "What happened to this project?"[1] don't make me confident that this software is mature enough for a stable Debian release... [0] https://github.com/AdolfVonKleist/Phonetisaurus#readme [1] https://github.com/AdolfVonKleist/Phonetisaurus/issues/3 -- Jakub Wilk
phonetisaurus in unstable
In #825236, Giulio asked me about uploading phonetisaurus to unstable. If I were the maintainer, I would hesitate to make such upload until the following is done: * 1001_fix_binaries_return_values.patch is accepted upstream. (Are they alive?) * The system-wide UTF8-CPP is used, instead of the embedded copy. * There's at least a minimal automated test suite. BTW, the small change I made to the 0.7.8-2 changelog (see the bottom of #701679) seems to have been lost... -- Jakub Wilk
Bug#826337: RFS: opengrm-ngram/1.3.0-1 -- opengrm n-gram library
* Giulio Paci <giuliop...@gmail.com>, 2016-06-04, 18:42: git clone git://anonscm.debian.org/collab-maint/opengrm-ngram.git Let me see: + * Drop 1001_fix_compilation_issues.patch. +No more needed. I'm not a native speaker of English, but shouldn't it be s/more/longer/? +Maximum number of ngrams to leave in model after pruning.Value less than zero means no target number, just use theta. Space is missing between "pruning." and "Value". There's an unholy mixture of tabs and spaces in update-man.sh: the line you added is indented by 8 spaces, whereas the surrounding lines are indented by tabs. There's a similar mixture of tabs and spaces in the definition of BACKUP in debian/rules. In #687563, I asked you to talk to upstream about insecure use of /tmp in the test suite. Did anything happen about this? Now that OpenFST is in unstable, should we upload this package to unstable too? -- Jakub Wilk
Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)
* Gianfranco Costamagna <locutusofb...@debian.org>, 2016-06-02, 17:07: "License: GPL-2+ with librtas exception" maybe something like License: GPL-2+-with-librtas-exception "FOO with BAR exception" is a valid licence syntax in DEP-5. If it is not appropriate to use it in this case, then you should explain why, because it's not obvious. the difference is just removing the spaces, IIRC lintian was triggering issues on dep-5 format when spaces were used. Spaces are not allowed in license names. But here the license name is just “GPL-2+”. Let me quote the relevant part of the spec: “An exception or clarification to a license is signalled in plain text, by appending ‘with exception’ to the short name.” -- Jakub Wilk
Re: help2man usage with pybuild / debhelper packaging workflow
* Wookey <woo...@wookware.org>, 2016-06-03, 17:10: Are there any successful examples of integration of help2man with a pybuild / debhelper workflow for an arbitrary number of scripts? help2man breaks cross-building so is best avoided if you can. Please just write a man page. Also, you can write much better manpages than help2man could generate. The quality of stuff help2man spews is often atrocious. Don't forget to forward the manpages upstream. :) -- Jakub Wilk
Bug#826135: RFS: lsvpd/1.7.6-1 ITP: lsvpd -- Utility to List Device Vital Product Data (VPD)
* Gianfranco Costamagna <costamagnagianfra...@yahoo.it>, 2016-06-02, 16:19: the same for libvpd applies here The same... what? I can't parse this sentence. "License: GPL-2+ with librtas exception" maybe something like License: GPL-2+-with-librtas-exception "FOO with BAR exception" is a valid licence syntax in DEP-5. If it is not appropriate to use it in this case, then you should explain why, because it's not obvious. [I didn't read rest of this mail because it made my head hurt. Gianfranco, please write complete sentences, and please don't top-post.] -- Jakub Wilk
Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
* Giulio Paci <giuliop...@gmail.com>, 2016-05-31, 16:18: I implemented a workaround that sets different limits for the build phase and the check phase. I like the idea. :-) 1eca96b4700b uploaded. -- Jakub Wilk
Re: dh_install globbing
* Dmitry Bogatov <kact...@gnu.org>, 2016-05-31, 14:15:
I can't reproduce it here:
$ grep -B1 html debian/*.install
#!/usr/bin/dh-exec
${RUNIT}/doc/*[a-z].html /usr/share/doc/runit/html
$ dpkg-buildpackage && dpkg -c ../runit_2.1.2-4_amd64.deb | grep /html/
...
I upgraded dh-exec from jessie to sid, and it started to work.
This is probably #801516.
Anyway, if replaced "${RUNIT}" with "runit-*" in the *.install file, you
wouldn't need dh-exec at all.
--
Jakub Wilk
Re: dh_install globbing
* Dmitry Bogatov <kact...@gnu.org>, 2016-05-31, 13:15:
$ git clone -b demonstrate
https://anonscm.debian.org/cgit/users/kaction-guest/runit.git/
Glob in 'runit.install'. Try to build package, and notice, that no html
files installed at all.
I can't reproduce it here:
$ grep -B1 html debian/*.install
#!/usr/bin/dh-exec
${RUNIT}/doc/*[a-z].html /usr/share/doc/runit/html
$ dpkg-buildpackage && dpkg -c ../runit_2.1.2-4_amd64.deb | grep /html/
...
drwxr-xr-x root/root 0 2016-05-31 12:51 ./usr/share/doc/runit/html/
-rw-r--r-- root/root 8164 2014-08-10 20:22
./usr/share/doc/runit/html/benefits.html
-rw-r--r-- root/root 1382 2014-08-10 20:22
./usr/share/doc/runit/html/dependencies.html
-rw-r--r-- root/root 12586 2014-08-10 20:22
./usr/share/doc/runit/html/faq.html
-rw-r--r-- root/root 11264 2014-08-10 20:22
./usr/share/doc/runit/html/index.html
-rw-r--r-- root/root 1639 2014-08-10 20:22
./usr/share/doc/runit/html/install.html
-rw-r--r-- root/root 9362 2014-08-10 20:22
./usr/share/doc/runit/html/replaceinit.html
-rw-r--r-- root/root 3837 2014-08-10 20:22
./usr/share/doc/runit/html/runlevels.html
-rw-r--r-- root/root 25919 2014-08-10 20:22
./usr/share/doc/runit/html/runscripts.html
-rw-r--r-- root/root 5147 2014-08-10 20:22
./usr/share/doc/runit/html/upgrade.html
-rw-r--r-- root/root 917 2014-08-10 20:22
./usr/share/doc/runit/html/usedietlibc.html
-rw-r--r-- root/root 3101 2014-08-10 20:22
./usr/share/doc/runit/html/useinit.html
--
Jakub Wilk
Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
* Giulio Paci <giuliop...@gmail.com>, 2016-05-31, 09:33: I just checked the building status of openfst and noticed failures on arm architectures and on kfreebsd-amd64. On arm it seems to me that a timeout occurred, One suspicious thing I found in armhf build log is: /usr/bin/make -C . -j4 -k distclean but this machine has only 4GB of RAM. So our parallelism limits don't seem to be enforced. This line ifneq "$(wildcard /build/buildd-*/)" "" was supposed to detect if the package is being built on a buildd, but buildds do longer use build directories like this. I don't think there's any reliable and future-proof way to detect this, so I'd suggest to drop this ifneq (i.e., start limiting parallelism everywhere). on kfreebsd-amd64 it seems a compiler failure. I suspect that cc1plus was killed by OOM killer, for the same reason as above. -- Jakub Wilk
Re: dh_install globbing
* Dmitry Bogatov <kact...@gnu.org>, 2016-05-30, 18:27: I want dh_install to install according following globbing: src/doc/*[a-z].html /usr/share/doc/runit/html (There is also html pages in form foo.1.html, which duplicate man pages. I do not want to install them.) But it does not work -- nothing is installed. dh_install(1) does not specify glob rules, but plain star (src/doc/*.html) works. The rules are documented in debhelper(1) manpage: “you can use standard shell wildcard characters (? and * and [..] character classes) in the [config] files”. Even if [] wasn't supported, in compat >=5 dh_install is supposed to fail if wildcard expands to nothing. Can you show us the source package, so that we can see what's going on? -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer <jre.wine...@gmail.com>, 2016-05-29, 17:37: Should I put your coyright and the MIT/X11 (BSD like) license in the script, as seen in dctypes2elf? Yes, please do. -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer <jre.wine...@gmail.com>, 2016-05-27, 20:17: I think I have it working now in wine to automatically generate a list of runtime dependencies. I based it on Jakub's suggestions, however I didn't go for creating a "dependency binary". For one I did get results this way, but unfortunately I neither really know python nor perl which is usually used in wine packaging, in order to cleanly implement it there. I've attached shell implementation of SONAMEs-to-ELF converter. sonames=$(shell grep "^\#define SONAME_" include/config.h | cut -d\" -f2) paths=/usr /usr/lib /lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) /usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) dlopenRecommends=$(shell \ for soname in $(sonames); do \ for path in $(paths); do \ file=$$(echo $$path/$$soname | sed "s|//|/|g"); \ [ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\) */\\1,/" && break || true; \ done; \ done) The problem with $(shell) constructs is that they ignore errors. Please avoid putting complicated code in them. -- Jakub Wilk #!/bin/sh set -e -u if [ $# = 0 ] || tty <&1 >/dev/null then printf 'Usage: %s SONAME... > ELF\n' "$0" exit 1 fi tmpdir=$(mktemp -d -t sonames2elf.XX) cd "$tmpdir" printf 'INPUT(%s)\n' "$@" > libeverything.so gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf cat elf rm -rf "$tmpdir"
Bug#825237: RFS: mrpt/1:1.4.0-1 [ITA] [RC]
* Sean Whitton <spwhit...@spwhitton.name>, 2016-05-27, 17:15: I think you should use a suffix other than -dbg because people expect -dbg to be detached debugging symbols. You could write to debian-de...@lists.debian.org and/or debian-mentors@lists.debian.org to see if anyone is aware of a precedent; Hey, we are already on -mentors. :-) I don't expect -dbg to be only detached debugging symbols. Actually, with the advent of automatic debug packages, symbols-only -dbg packages are (hopefully) going to become extinct. The most prominent precedent is probably pythonX.Y-dbg. -- Jakub Wilk
Re: [Help] Re: Bug#825461: staden: FTBFS in testing
* Jakub Wilk <jw...@debian.org>, 2016-05-27, 10:05: gcc -shared -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include -I"/usr/include/tcl8.6/tk-private/generic" -I"/usr/include/tcl8.6/tk-private/unix" -I"/usr/include/tcl8.6/tk-private/generic/ttk" -I"/usr/include/tcl8.6/tcl-private/generic" -I"/usr/include/tcl8.6/tcl-private/unix" -I/build/staden-2.0.0+b10/./seq_utils -I/build/staden-2.0.0+b10 -DSVN_VERSION="" -fPIC -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include -I"/usr/include/tcl8.6/tk-private/generic" -I"/usr/include/tcl8.6/tk-private/unix" -I"/usr/include/tcl8.6/tk-private/generic/ttk" -I"/usr/include/tcl8.6/tcl-private/generic" -I"/usr/include/tcl8.6/tcl-private/unix" -I/build/staden-2.0.0+b10/./seq_utils -I/build/staden-2.0.0+b10 -DSVN_VERSION="" -fPIC -L/build/staden-2.0.0+b10/lib -Wl,-z,relro -Wl,--export-dynamic -Wl,-rpath,/usr/lib/staden -o /build/staden-2.0.0+b10/lib/libtk_utils.so cli_arg.o tclXkeylist.o tclXutil.o tcl_utils.o tcl_debug.o misc.o init.o text_output.o tkRaster.o tkRasterBuiltIn.o sheet.o tkSheet.o tkSheet_common.o trace_print.o postscript.o split.o tkTrace.o tkTraceComp.o tkTraceIO.o tkTraceDisp.o capture.o canvas_box.o ruler_tick.o restriction_enzyme_map.o element_canvas.o container.o container_ruler.o tcl_io_lib.o -L/usr/lib/x86_64-linux-gnu -lstaden-read -fPIE -pie -Wl,-z,relro -Wl,-z,now -lm -lpthread -lcurl -lz -L/usr/lib/x86_64-linux-gnu -ltk8.6 -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -lX11 -lXss -lXext -lXft -lfontconfig -lfreetype -lfontconfig -lpthread -ldl -lz -lpthread -lieee -lm -lmisc -lpng -lz This is trying to build a shared library with -pie, which is not going to fly. -pie (and -fPIE) is only for executables. Now, I don't see any mention of pie in debian/rules, or in the old build log, so I guess this flag must have come from a (broken) library. If you grep for -pie in config.log you get this: IO_LIB_LDFLAGS='-L/usr/lib/i386-linux-gnu -lstaden-read -fPIE -pie -Wl,-z,relro -Wl,-z,now -lm -lpthread -lcurl -lz' which was apparently generated by: $ io_lib-config --libs -L/usr/lib/i386-linux-gnu -lstaden-read -fPIE -pie -Wl,-z,relro -Wl,-z,now -lm -lpthread -lcurl -lz This will have to be fixed in libstaden-read-dev. -- Jakub Wilk
Re: [Help] Re: Bug#825461: staden: FTBFS in testing
* Andreas Tille <andr...@an3as.eu>, 2016-05-27, 09:27: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status The command line that causes this is: gcc -shared -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include -I"/usr/include/tcl8.6/tk-private/generic" -I"/usr/include/tcl8.6/tk-private/unix" -I"/usr/include/tcl8.6/tk-private/generic/ttk" -I"/usr/include/tcl8.6/tcl-private/generic" -I"/usr/include/tcl8.6/tcl-private/unix" -I/build/staden-2.0.0+b10/./seq_utils -I/build/staden-2.0.0+b10 -DSVN_VERSION="" -fPIC -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include -I"/usr/include/tcl8.6/tk-private/generic" -I"/usr/include/tcl8.6/tk-private/unix" -I"/usr/include/tcl8.6/tk-private/generic/ttk" -I"/usr/include/tcl8.6/tcl-private/generic" -I"/usr/include/tcl8.6/tcl-private/unix" -I/build/staden-2.0.0+b10/./seq_utils -I/build/staden-2.0.0+b10 -DSVN_VERSION="" -fPIC -L/build/staden-2.0.0+b10/lib -Wl,-z,relro -Wl,--export-dynamic -Wl,-rpath,/usr/lib/staden -o /build/staden-2.0.0+b10/lib/libtk_utils.so cli_arg.o tclXkeylist.o tclXutil.o tcl_utils.o tcl_debug.o misc.o init.o text_output.o tkRaster.o tkRasterBuiltIn.o sheet.o tkSheet.o tkSheet_common.o trace_print.o postscript.o split.o tkTrace.o tkTraceComp.o tkTraceIO.o tkTraceDisp.o capture.o canvas_box.o ruler_tick.o restriction_enzyme_map.o element_canvas.o container.o container_ruler.o tcl_io_lib.o -L/usr/lib/x86_64-linux-gnu -lstaden-read -fPIE -pie -Wl,-z,relro -Wl,-z,now -lm -lpthread -lcurl -lz -L/usr/lib/x86_64-linux-gnu -ltk8.6 -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -lX11 -lXss -lXext -lXft -lfontconfig -lfreetype -lfontconfig -lpthread -ldl -lz -lpthread -lieee -lm -lmisc -lpng -lz This is trying to build a shared library with -pie, which is not going to fly. -pie (and -fPIE) is only for executables. Now, I don't see any mention of pie in debian/rules, or in the old build log, so I guess this flag must have come from a (broken) library. -- Jakub Wilk
Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
* Giulio Paci <giuliop...@gmail.com>, 2016-05-25, 19:10: https://anonscm.debian.org/git/collab-maint/openfst.git [...] I added some code to restrict the build to mips, mipsel and hurd-i386. Just like the last time[1], -O0 wasn't enough to get the tests built on mips: | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/algo_test_log algo_test_log-algo_test.o ../lib/.libs/libfst.so -lm -ldl | algo_test_log-algo_test.o: In function `fst::LookAheadCompose(fst::Fst<fst::ArcTpl<fst::TropicalWeightTpl > > const&, fst::Fst<fst::ArcTpl<fst::TropicalWeightTpl > > const&, fst::MutableFst<fst::ArcTpl<fst::TropicalWeightTpl > >*)': | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:54:(.text+0x304): relocation truncated to fit: R_MIPS_GOT16 against `__stack_chk_guard@@GLIBC_2.4' | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:67:(.text+0x4e8): relocation truncated to fit: R_MIPS_GOT16 against `__stack_chk_guard@@GLIBC_2.4' | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:55:(.text+0x588): relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0' | /home/jwilk/openfst-1.5.3+r2/src/test/./algo_test.h:67:(.text+0x598): relocation truncated to fit: R_MIPS_CALL16 against `__stack_chk_fail@@GLIBC_2.4' | algo_test_log-algo_test.o: In function `main': | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:41:(.text+0x5f4): relocation truncated to fit: R_MIPS_GOT16 against `__stack_chk_guard@@GLIBC_2.4' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:42:(.text+0x600): relocation truncated to fit: R_MIPS_GOT16 against `FLAGS_fst_verify_properties' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:43:(.text+0x60c): relocation truncated to fit: R_MIPS_GOT16 against `FailedNewHandler()' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:43:(.text+0x610): relocation truncated to fit: R_MIPS_CALL16 against `std::set_new_handler(void (*)())@@GLIBCXX_3.4' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:44:(.text+0x64c): relocation truncated to fit: R_MIPS_CALL16 against `SetFlags(char const*, int*, char***, bool, char const*)' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:48:(.text+0x674): relocation truncated to fit: R_MIPS_CALL16 against `time@@GLIBC_2.0' | /home/jwilk/openfst-1.5.3+r2/src/test/algo_test.cc:49:(.text+0x6a4): additional relocation overflows omitted from the output | collect2: error: ld returned 1 exit status | Makefile:641: recipe for target 'algo_test_log' failed Appending "-mxgot" to CXXFLAGS fixed this error. Inconveniently, "-mxgot" is not a valid option on hurd, so you'll have to add another ifneq. Minor stylistic nitpick: I find ifneq "$(foobar)" "" much more readable than ifneq (,$(foobar)) [1] https://lists.debian.org/20160418195914.ga5...@jwilk.net Do you think phonetisaurus [0] can also be uploaded to unstable? [0] https://anonscm.debian.org/cgit/collab-maint/phonetisaurus.git I'll have a look at it later. -- Jakub Wilk
Bug#825236: RFS: openfst/1.5.3-1 -- weighted finite-state transducers library
Control: tags -1 + moreinfo * Giulio Paci <giuliop...@gmail.com>, 2016-05-24, 23:38: https://anonscm.debian.org/git/collab-maint/openfst.git The package FTBFS (on i386): | Making check in test | make[3]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' | /usr/bin/make fst_test weight_test algo_test_log algo_test_tropical algo_test_minmax algo_test_lexicographic algo_test_power | make[4]: Entering directory '/build/openfst-aOvp6g/openfst-1.5.3/src/test' | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o fst_test.o fst_test.cc | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z,relro -Wl,-z,now -o fst_test fst_test.o ../lib/libfst.la -lm -ldl | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/fst_test fst_test.o ../lib/.libs/libfst.so -lm -ldl | g++ -DHAVE_CONFIG_H -I./../include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o weight_test.o weight_test.cc | /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z,relro -Wl,-z,now -o weight_test weight_test.o ../lib/libfst.la -lm -ldl | libtool: link: g++ -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/weight_test weight_test.o ../lib/.libs/libfst.so -lm -ldl | g++ -DHAVE_CONFIG_H -DTEST_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -g -O0 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -c -o algo_test_log-algo_test.o `test -f 'algo_test.cc' || echo './'`algo_test.cc | In file included from algo_test.cc:6:0: | ./algo_test.h:9:24: fatal error: fst/fstlib.h: No such file or directory | compilation terminated. (I tested 1.5.3-1, but I don't see anything changed in 1.5.3+r2-1 that would fix it...) Please reduce optimization level to -O0 only on architectures where it is strictly required. Otherwise there's a risk that bugs that only trigger with optimization enabled go under our radar even on mainstream archs. I'm fine with uploading openfst to unstable. BTW, while supporting as many architectures as possible is of course a desirable goal, supporting all of them is not strictly necessary. Stretch RC policy[0] says: “Packages must autobuild without failure on all architectures on which they are supported. Packages must be supported on as many architectures as is reasonably possible. Packages are assumed to be supported on all architectures for which they have previously built successfully. Prior builds for unsupported architectures must be removed from the archive (contact -release or ftpmaster if this is the case).” Since openfst would be a new package in unstable, missing mips* builds wouldn't be release-critical or block testing migration. [0] https://release.debian.org/stretch/rc_policy.txt -- Jakub Wilk
Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]
* Nathan Osman <nat...@quickmediasolutions.com>, 2016-05-23, 20:37: I worked around this problem by manually setting $HOME to /tmp in debian/rules. Please let me know if there is anything wrong with this. Yes, this is very wrong. /tmp is world-writable and therefore not suitable for a home directory. In some cases setting HOME=/tmp could allow a malicious local user to execute arbitrary code with the privileges of the building user. Please set HOME to a subdirectory of cwd, which can be safely assumed to be writable only by the building user. $(CURDIR)/debian/tmp/tmp might be a convenient choice. -- Jakub Wilk
Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
There's a new release in the git repo:
https://git.sur5r.net/tio/
* Jakub Wilk <jw...@debian.org>, 2016-05-07, 14:44:
Please run autoreconf at build time. (That should be a matter of
replacing the "autotools-dev" addon with "autoreconf".)
This is now fixed, but now-unused autotools-dev is still in
Build-Depends.
My git doesn't like the certificate:
fatal: unable to access 'https://git.sur5r.net/tio/': server certificate
verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
On IRC I was told this is intentional. Note to self: to disable
certificate validation, pass "-c http.sslVerify=false" to git.
Our infrastructure doesn't support watch files in version 4 yet, so
please downgrade it to 3.
Please do s/http/https/ in the Homepage field.
The package synopsis should start with a lowercase letter; see DevRef
§6.2.2.
"Forwarded: not-needed" should be "Forwarded: yes", shouldn't it?
I'd rather have only a single changelog entry for the initial release.
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
This seem unnecessary, given that this program doesn't link to any
libraries (except implicitly to libc).
Now some nitpicking about upstream code (to be fixed at your (or
upstream's) leisure):
printf("License GPLv2: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl-2.0.html>.\n");
I'd do s/v2/v2+/.
Or maybe less repetitively: s/ GPLv2:/:/.
option.baudrate = baudrate = atoi(optarg);
atoi() doesn't do any error checking. (In fact, POSIX says that "if the
value cannot be represented, the behavior is undefined".) I'd recommend
using strtol() instead.
--
Jakub Wilk
Bug#820704: RFS: subuser/0.5.6-3 [ITP]
* Andrey Rahmatullin <w...@debian.org>, 2016-05-21, 21:58: - Add --update option to dev command - Fix /dev/dri permissions issues - Fix encoding bug when communicating with Docker daemon - Improve support for packaging subuser Putting upstream changelog entries to debian/changelog is not an accepted practice either. For initial release it makes of course little sense, but in general I don't think there's anything wrong with including summary of upstream changes in Debian changelog. That's what I do in my packages (when I'm not overly lazy...), and I know a few other developers do this too. Upstream stuff is often the least boring part of apt-listchanges output. :-) -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer <jre.wine...@gmail.com>, 2016-05-19, 16:57: First off, I'm not sure about every single dependency if it is needed at all. Quick grep over the *.dll.so indeed shows that they use a bunch of libraries you mentioned: $ strings /usr/lib/i386-linux-gnu/wine/*.dll.so | grep '^lib.*[.]so[.]' | sort -u | grep -v '!' libGLU.so.1 libOSMesa.so.8 libOpenCL.so.1 libX11.so.6 libXext.so.6 libc.so.6 libfontconfig.so.1 libfreetype.so.6 libgnutls.so.30 libjpeg.so.62 liblber-2.4.so.2 liblcms2.so.2 libldap_r-2.4.so.2 libm.so.6 libncurses.so.5 libodbc.so.2 libopenal.so.1 libpcap.so.0.8 libpng16.so.16 libpthread.so.0 libresolv.so.2 libtiff.so.5 libwine.so.1 libxml2.so.2 libxslt.so.1 libz.so.1 I guess a better method of obtaining the list of used shared libraries is to grep for "SONAME_" in include/config.h (after it was created by the configure script). Once you have the list of needed shlibs, the simplest way to compute package dependency is to create an ELF that depends on all of them, and then use dpkg-shlibdeps against it. You can steal the idea of how to create such ELF here: https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf -- Jakub Wilk
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
* lumin <cdlumin...@gmail.com>, 2016-05-18, 12:44: * add debian/upstream/metadata , but lintian says W: caffe source: upstream-metadata-yaml-invalid Is there anything wrong with this file? I have no idea I've just commited fix for Lintian to include validation error in the output, so in the next version it will be: W: caffe source: upstream-metadata-yaml-invalid mapping values are not allowed in this context (at document 1, line 3, column 16) ...which is (hopefully) more helpful. But in the future, don't count on Lintian contributors reading debian-mentors. If you find Lintian output misleading or unhelpful, please file bugs! :-) -- Jakub Wilk
Re: a few questions on ITP shadowsocks-libev before formal RFS
* Roger Shimizu <rogershim...@gmail.com>, 2016-05-18, 02:14: I'm doing ITP packaging on shadowsocks-libev. I have a few questions in detail. I have set up a git repo on github: https://github.com/rogers0/shadowsocks-libev My current changes are pushed to branch: RFC Package builds fine with command: gbp buildpackage -us -uc --git-ignore-branch Some questions/issues that I'm not sure: - Upstream maintained debian/ folder long before, I'm going to keep the original debian/changelog. So I should also keep the upstream as maintainer, and add myself as the uploader? It doesn't matter who maintained the package in the package. What matters is who is going to maintain it now for Debian. Did you ask upstream to co-maintain it with you? You certainly shouldn't put anyone to Maintainer/Uploaders without their consent. - The package is mainly GPLv3, but it links to OpenSSL library, is that OK? GPL+OpenSSL is no-no. README says that mbedtls, which is GPL-compatible, can be used as an alternative to OpenSSL, so you should try it. - Upstream repo includes library source code of libev, libsodium, libudns. Is it OK to keep as it is, or have to remove and make another source tarball? As long as they are DFSG-free, you can keep them in the source package. Just make sure they are not used at build time. This is best achieved by "rm -rf"ing them early in the build process. (If you're using dh, then beginning of override_dh_auto_build is probably the best place.) - The answer of above question may affect: whether I should remove copyright of library libev, libsodium, libudns from debian/copyright? If you keep them in .orig.tar, then you must also keep them in debian/copyright. If you remove them from .orig.tar, then remove them from debian/copyright too. - Is it needed to add "dh_autoreconf" in debian/rules? It's not required by policy, but many sponsors will (rightfully!) insist to regenerate autotools stuff from source. - I have no idea on the following lintian error, because postrm/postinst scripts are generated by dh E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-local This seems to be caused by passing --no-start to dh_installinit: dh_installinit --no-start --name=shadowsocks-libev-server@ dh_installinit --no-start --name=shadowsocks-libev-tunnel@ dh_installinit --no-start --name=shadowsocks-libev-redir@ dh_installinit --no-start --name=shadowsocks-libev-local@ My initsystem-fu is too weak to tell whether it's a d/rules bug, debhelper bug, or Lintian bug, or just something that should be overridden. -- Jakub Wilk
Re: package name for what upstream calls protobuf3
* Jonathon Love <j...@thon.love>, 2016-05-18, 18:45: i'm in the process of packaging protobuf3: https://github.com/Pr0Ger/protobuf3 this is an implementation of protocol buffers 2 for python 3. according to debian policy, this should be named python3-protobuf3, but i think this name isn't ideal I don't know anything about anything about Python, but if packaging policy says that the package name should be named after the module name, and it turns out that the package name is too generic or misleading or otherwise inadequate, then that's only because the module name had exactly the same problem. So please get it renamed upstream. This is not something that should be papered over by deviating from the usual naming policy. -- Jakub Wilk
