Bug#834078: marked as done (RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper)
Your message dated Fri, 12 Aug 2016 09:23:19 + (UTC) with message-id <864192905.22768544.1470993799476.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#834078: RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper has caused the Debian Bug report #834078, regarding RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 834078: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834078 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Control: block 832851 by -1 Dear mentors, I am looking for a sponsor for an NMU of python-argh, fixing a stretch RC bug (older than 7 days and no maintainer activity). * Package name: python-argh Version : 0.26.1-1.1 Upstream Author : Andrey Mikhailenko * URL : http://pypi.python.org/pypi/argh * License : LGPL-3.0+ Section : python Changes since the last upload: * Non-maintainer upload. * Update 0001-fix-unit-tests.patch for newer sbuild (Closes: #832851). The LANG environment variable might not be set. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/p/python-argh/python-argh_0.26.1-1.1.dsc Thanks. -- Sean Whitton signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for an NMU of python-argh, fixing a stretch RC>bug >(older than 7 days and no maintainer activity). it's in! thanks, G.--- End Message ---
Bug#825390: missing ITP
Hi Emily, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#827590: missing ITP
Hi Lumin, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#827895: missing ITP
Hi Lumin, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#822149: missing ITP
Hi Herbert, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#829081: missing ITP
Hi Thomas, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#822613: missing ITP
Hi Rohan, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#827582: missing ITP
Hi Lumin, Where is the ITP? There should be one, see the instructions at "new packages": https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage Regards, Bart Martens
Bug#827590: missing ITP
Control: retitle 826791 ITP: lua-torch-trepl/0~20160613-g06128f9-1 -- A REPL for Troch Framework Control: block 826791 by 827590 Hi, the ITP is found now. On 12 August 2016 at 11:19, Bart Martens wrote: > Hi Lumin, > > Where is the ITP? There should be one, see the instructions at "new packages": > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage > > Regards, > > Bart Martens -- Best, Lumin
Bug#827895: missing ITP
Control: block 826794 by 827895 Hi, now the missing ITP is found. On 12 August 2016 at 11:23, Bart Martens wrote: > Hi Lumin, > > Where is the ITP? There should be one, see the instructions at "new packages": > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage > > Regards, > > Bart Martens -- Best, Lumin
Bug#834078: RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper
* Sean Whitton , 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
Bug#827582: missing ITP
Control: block 826793 by 827582 Hi, the missing ITP is found. On 12 August 2016 at 11:30, Bart Martens wrote: > Hi Lumin, > > Where is the ITP? There should be one, see the instructions at "new packages": > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage > > Regards, > > Bart Martens -- Best, Lumin
Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]
Gianfranco Costamagna writes: > Hi Ferenc and Etienne, > >>> It'd probably make sense to start with a jessie backport, where >>> this change is necessary, then branch off the wheezy backport from >>> that, and do the PKG_INSTALLDIR change only. > > fully agree > (do you mean, "the revert is necessary", right?) Right. >> Thank you Gianfranco and Ferenc for your inputs. I'll redo this as a >> jessie backport first. > > so, Ferenc, if you agree I can sponsor as soon as you give me an ack :) > Are you in the -backports ACL? in that case you might be able to upload > by yourself after the first upload in backports-new. Thanks, I'm in the backports ACL and I've become a DD on Wednesday, so I should be able to handle this upload myself. I've never sponsored an upload yet, so we'll see. If it does not work out or on occasions I'm unavailable, your help (both review and upload) will be much appreciated. -- Thanks, Feri
Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz
Hi, this version was a source only upload. If I build on my local machine emboss-data does not contain any dir /usr/share/man. However, the binary package on the Debian mirror contains /usr/share/man/man1 with has two symlinks which are identical to those in the emboss package. I can not reproduce this and I'm wondering why the source only upload creates files that are not created on a local build. Kind regards Andreas. On Thu, Aug 11, 2016 at 02:18:00PM +0200, Andreas Beckmann wrote: > Package: emboss,emboss-data > Version: 6.6.0+dfsg-4 > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite > > Hi, > > automatic installation tests of packages that share a file and at the > same time do not conflict by their package dependency relationships has > detected the following problem: > > Selecting previously unselected package emboss. > (Reading database ... > (Reading database ... 8365 files and directories currently installed.) > Preparing to unpack .../emboss_6.6.0+dfsg-4_amd64.deb ... > Unpacking emboss (6.6.0+dfsg-4) ... > dpkg: error processing archive > /var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb (--unpack): >trying to overwrite '/usr/share/man/man1/em_cons.1e.gz', which is also in > package emboss-data 6.6.0+dfsg-4 > Errors were encountered while processing: >/var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb > > This is a serious bug as it makes installation fail, and violates > sections 7.6.1 and 10.1 of the policy. An optimal solution would > consist in only one of the packages installing that file, and renaming > or removing the file in the other package. Depending on the > circumstances you might also consider Replace relations or file > diversions. If the conflicting situation cannot be resolved then, as a > last resort, the two packages have to declare a mutual > Conflict. Please take into account that Replaces, Conflicts and > diversions should only be used when packages provide different > implementations for the same functionality. > > > This bug is assigned to both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may > also register in the BTS that the other package is affected by the bug. > > Cheers, > > Andreas > > PS: for more information about the detection of file overwrite errors > of this kind see https://qa.debian.org/dose/file-overwrites.html > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#834146: RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP]
Package: sponsorship-requests Severity: wishlist Debomatic-amd64: PASS http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-sys/0~20160415-g8d2b8fa-1/buildlog * Changed target release to experimental * misc updates Dear mentors, I am looking for a sponsor for my package "lua-torch-sys" * Package name: lua-torch-sys Version : 0~20160415-g8d2b8fa-1 Upstream Author : torch developers * URL : github.com/torch/sys * License : BSD-3-Clause Section : interpreters It builds those binary packages: lua-torch-sys - System Package for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-sys Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-sys/lua-torch-sys_0~20160415-g8d2b8fa-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: lua-torch-sys (0~20160415-g8d2b8fa-1) experimental; urgency=low * Initial release. Closes: #826792 -- Best, Lumin
Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz
Hi, >this version was a source only upload. If I build on my local machine >emboss-data does not contain any dir /usr/share/man. However, the >binary package on the Debian mirror contains /usr/share/man/man1 with >has two symlinks which are identical to those in the emboss package. seems you didn't split the dh_link into an arch-indep and an arch-dep target, and you do the same link regardless of which package they will go inside. so, the links for the arch-indep seems to be created when building the arch-dep packages. >I can not reproduce this and I'm wondering why the source only upload >creates files that are not created on a local build. probably your local build is broken and builds only arch-dep packages? I can't say without a build log. (note: I didn't really debug this issue, the rules file seems overly complicated to me) G.
Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz
Hi, On 12/08/16 14:58, Andreas Tille wrote: > Hi, > > this version was a source only upload. If I build on my local machine > emboss-data does not contain any dir /usr/share/man. However, the > binary package on the Debian mirror contains /usr/share/man/man1 with > has two symlinks which are identical to those in the emboss package. > > I can not reproduce this and I'm wondering why the source only upload > creates files that are not created on a local build. debian/rules contains: override_dh_installman: dh_installman -a -p emboss for i in $(RENAMED) ; \ do dh_link usr/share/man/man1/$$i.1e.gz usr/share/man/man1/em_$$i.1e.gz ; \ done dh_link will install the symlink into the first package in debhelper's list of packages. When doing an arch:amd64 upload this is "emboss", but when doing an arch:all upload (which happens when you do a source uploaded) this is "emboss-data". Thus you get two symlinks which conflict with each other. You should be able to reproduce this by doing two separate builds: One with dpkg-buildpackage -B One with dpkg-buildpackage -A And comparing the generated debs. The simple solution is to use "dh_link -pemboss" to force the symlinks to be installed into that package. James signature.asc Description: OpenPGP digital signature
Bug#834146: marked as done (RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP])
Your message dated Fri, 12 Aug 2016 14:13:59 + (UTC) with message-id <1745796527.23060868.1471011239616.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#834146: RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP] has caused the Debian Bug report #834146, regarding RFS: lua-torch-sys/0~20160415-g8d2b8fa-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 834146: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834146 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Debomatic-amd64: PASS http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-sys/0~20160415-g8d2b8fa-1/buildlog * Changed target release to experimental * misc updates Dear mentors, I am looking for a sponsor for my package "lua-torch-sys" * Package name: lua-torch-sys Version : 0~20160415-g8d2b8fa-1 Upstream Author : torch developers * URL : github.com/torch/sys * License : BSD-3-Clause Section : interpreters It builds those binary packages: lua-torch-sys - System Package for Torch Framework To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-torch-sys Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-torch-sys/lua-torch-sys_0~20160415-g8d2b8fa-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: lua-torch-sys (0~20160415-g8d2b8fa-1) experimental; urgency=low * Initial release. Closes: #826792 -- Best, Lumin --- End Message --- --- Begin Message --- Hi, >Debomatic-amd64: PASS >http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-sys/0~20160415-g8d2b8fa-1/buildlog ack done. G.--- End Message ---
Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
Hi, >This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev" >package. It is a runtime dependency. I'll leave a comment there. >Keeping this runtime B-D there because it declares explicit dependency >relationship. oh, ok >I've thought about spliting it up -- inspece verbose dh build and >extract the library compilation commands into d/rules -- however this >makes d/rules complicated with hardcoded compiles. > >Seems that dh_lua didn't foresee such a demand, so the above method is >the way first came up in my mind. > >Now that the symlink just works fine ... > >1. split then up with hardcoded compile >2. create a new package that ships just a simlink > >How do you like it? no, seems worse. lets keep it >Suggests: lua-torch-dok, lua-torch-xlua they need to be packaged first. G. -- Best, Lumin
Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]
Hi, updated the lua-torch-trepl package, including the change of release to experimental. https://mentors.debian.net/package/lua-torch-trepl it passed debomatic-amd64 build: http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-1/buildlog Concerning the readline.so problem, if this library is split into another package, then what name the package should take becomes a problem. Since it installs a symlink File: '/usr/lib/x86_64-linux-gnu/lua/5.1/readline.so' -> 'treplutils.so' which means it can't use the `lib*` namespace. Moreover, it is confusing if shipped in a `libtorch-readline` package (libtorch-th ships /usr/lib/x86_64-linux-gnu/libTH.so.0). Oh what about lua-torch-trepl-readline ? but this package used `lua-*` namespace and ships no lua file. with command [1] and [2] and [3] a readline.so can be separately generated but I think there is no much need, although not elegant. 1. I don't know how to name the package shipping only that symlink. 2. lua loads symbols dynamically, such symlink won't harm functionality. Well, that's the reason why I didn't change the readline.so symlink. Please comment, thanks. [1] libtool --silent --tag=CC --mode=compile cc -c -g -O2 -fdebug-prefix-map=/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr//include/lua5.1 -I/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl -Wall -Wextra -o /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo readline.c [2] libtool --silent --tag=CC --mode=link cc \ -rpath /usr//lib/x86_64-linux-gnu -version-info 0:0:0 -Wl,--no-add-needed \ -o /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/liblua5.1-torch-trepl.la \ /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/utils.lo /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo \ -fPIE -pie -Wl,-z,relro -Wl,-z,now -L/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl -lreadline [3] ln -sf ./.libs/liblua5.1-torch-trepl.so.0.0.0 \ /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/treplutils.so On 7 August 2016 at 16:16, Lumin wrote: > On 4 August 2016 at 18:42, Gianfranco Costamagna > wrote: > >> why do not build-depend on the dev package? >> I'm talking about "lua-torch-torch7" > > This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev" > package. It is a runtime dependency. I'll leave a comment there. > > Keeping this runtime B-D there because it declares explicit dependency > relationship. > >> also, there is some sadness in the libreadline.so link, are you sure there >> is no better way to fix that? >> what about a package split? > > I've thought about spliting it up -- inspece verbose dh build and > extract the library compilation commands into d/rules -- however this > makes d/rules complicated with hardcoded compiles. > > Seems that dh_lua didn't foresee such a demand, so the above method is > the way first came up in my mind. > > Now that the symlink just works fine ... > > 1. split then up with hardcoded compile > 2. create a new package that ships just a simlink > > How do you like it? > >> cheers, >> >> G. > > > > -- > Best, > Lumin -- Best, Lumin
Bug#834078: RFS: python-argh/0.26.1-1.1 [NMU, RC] -- simple argparse wrapper
control: reopen -1 control: retitle -1 RFS: python-argh/0.26.1-1.2 [NMU] -- simple argparse wrapper control: severity -1 normal Hello, On Fri, Aug 12, 2016 at 02:22:09PM +0200, Jakub Wilk wrote: > 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). I agree -- thanks for your feedback. I'm reopening this RFS for another NMU (this time, I would like to suggest an upload to DELAYED/10). New changelog: * Non-maintainer upload. * Drop parts of 0001-fix-unit-tests.patch touching test_interaction.py. * Fix the Unicode encoding test by setting LC_ALL in d/rules. This fix is more general as the LANG var can be overridden by LC_* vars (see locale(7)). Thanks to Jakub Wilk for pointing this out and suggesting the improved fix. Download from mentors: dget -x http://mentors.debian.net/debian/pool/main/p/python-argh/python-argh_0.26.1-1.2.dsc -- Sean Whitton signature.asc Description: PGP signature
Bug#834185: RFS: osmose-emulator/1.0-1 [ITP] -- Sega Master System and Game Gear console emulator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "osmose-emulator" * Package name: osmose-emulator Version : 1.0-1 Upstream Author : Bruno Vedder * URL : http://bcz.asterope.fr/osmose.htm * License : GPL-3+ Section : games It builds those binary packages: osmose-emulator - Sega Master System and Game Gear console emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/osmose-emulator Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose- emulator_1.0-1.dsc More information about osmose-emulator can be obtained from https://github.com/coringao/osmose-emulator. Regards, Carlos Donizete Froes -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#833187: RFS: yuma123/2.8-1 [ITP] -- netconf/YANG toolchain
Vincent, The packaging project git I work with is available here https://sourceforge.net/projects/pkg-yuma123/ On 08/06/2016 10:10 PM, Vincent Bernat wrote: How should netconfd be running? I see that netconf-subsystem should be configured inside OpenSSH. What about netconfd? Is it spawned by netconf-subsystem? `netconfd` started without any arguments creates UNIX socket /tmp/ncxserver.sock and listens for connections. `netconf-subsystem` is called from OpenSSH and connects to /tmp/ncxserver.sock for each ssh client connecting to the netconf subsystem. `man netconfd` or the wiki guides e.g. http://www.yuma123.org/wiki/index.php/Yuma_Quickstart_Guide#NETCONF_Server contain detailed information. Vladimir
Bug#834205: RFS: dh-elpa/1.1 -- Debian helper tools for packaging emacs lisp extensions
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a new release of dh-elpa. My co-maintainer is a DD but his key in the uploaders' keyring has expired and he can't replace it for a while. * Package name: dh-elpa Version : 1.1 Upstream Author : David Bremner & Sean Whitton * URL : https://pkg-emacsen.alioth.debian.org/ * License : GPL-3+ Section : devel Changes since the last upload: * Attempt to sanitise versions from DEB_* env vars so that Emacs accepts them as ELPA package version strings. Download with dget: dget -x http://mentors.debian.net/debian/pool/main/d/dh-elpa/dh-elpa_1.1.dsc Or build it with gbp: gbp clone https://anonscm.debian.org/git/pkg-emacsen/pkg/dh-elpa.git git checkout debian/1.1 git verify-tag debian/1.1 # if you have my key gbp buildpackage Thanks. -- Sean Whitton signature.asc Description: PGP signature
