Bug#875511: RFS: qmdnsengine/0.1.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "qmdnsengine" * Package name: qmdnsengine Version : 0.1.0-1 Upstream Author : Nathan Osman * URL : https://github.com/nitroshare/qmdnsengine * License : MIT Section : libs It builds those binary packages: libqmdnsengine-dev - Multicast DNS library for Qt applications - development files libqmdnsengine-doc - Multicast DNS library for Qt applications - documentation libqmdnsengine-examples - Multicast DNS library for Qt applications - examples libqmdnsengine0 - Multicast DNS library for Qt applications To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qmdnsengine Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qmdnsengine/qmdnsengine_0.1.0-1.dsc More information about qmdnsegine can be obtained from https://github.com/nitroshare/qmdnsengine. Regards, Nathan Osman
Bug#875270: ITP: qmdnsengine -- Multicast DNS library for Qt applications
Package: wnpp Severity: wishlist Owner: Nathan Osman * Package name: qmdnsengine Version : 0.1.0 Upstream Author : Nathan Osman * URL : https://github.com/nitroshare/qmdnsengine * License : MIT Programming Lang: C++ Description : Multicast DNS library for Qt applications QMdnsEngine provides an implementation of multicast DNS as per RFC 6762. Some of QMdnsEngine's features include: - Provide mDNS services on the local network - Respond to mDNS queries from other devices - Browse mDNS services provided by other devices on the local network - Resolve services to IPv4 and IPv6 addresses The library is fully documented and includes a comprehensive test suite.
Bug#840692: nemo-python: plugin is not recognized or loaded by Nemo
Package: nemo-python Version: 3.0.0-3 Severity: grave Justification: renders package unusable Dear Maintainer, The nemo-python extension is not displayed in the "Extensions" list under Edit->Plugins. This is further confirmed by the fact that none of the Python extensions I have installed work. Running Nemo under KDE, Gnome, and Cinnamon doesn't appear to make any difference. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nemo-python depends on: ii gir1.2-nemo-3.0 3.0.6-3 ii libatk1.0-0 2.22.0-1 ii libc62.24-3 ii libcairo-gobject21.14.6-1+b1 ii libcairo21.14.6-1+b1 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-0 2.50.1-1 ii libgtk-3-0 3.22.1-1 ii libnemo-extension1 3.0.6-3 ii libpango-1.0-0 1.40.3-2 ii libpangocairo-1.0-0 1.40.3-2 ii libpython2.7 2.7.12-3+b1 nemo-python recommends no packages. nemo-python suggests no packages. -- no debconf information
Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]
Hi Mattia, Perhaps it would help if I explained exactly what that test is doing. One of the possible uses for this library is to provide a local HTTP server that would be accessible only to the current user. This is done by creating a special token and putting it into a file that is only readable by the user (by doing the equivalent of "chmod 600"). Other applications running under the user's account can read the file and include the token when making HTTP requests to the server. Other users won't be able to read the file and won't be able to include the token with HTTP requests. By default, this special file is created in the user's home directory. The test suite uses the default location and fails when it can't determine the home directory. By setting $HOME to /tmp, the test suite is able to use /tmp as if it were the user's home directory. Please let me know if I should change debian/rules back to using a hardcoded value for /tmp or if I should leave it as it is now (using $TMPDIR but falling back to /tmp). - Nathan On 2016-05-24 10:48 AM, Mattia Rizzolo wrote: On Tue, May 24, 2016 at 10:43:59AM -0700, Nathan Osman wrote: First of all, I apologize for the mix-up. I wasn't paying very close attention to who was sending the emails. I think I've got it all straightened out now :) Nevermind :) As described below, I've made the changes you requested and made the adjustment for observing TMPDIR as Mattia suggested. Please let me know if you have any further questions or if there are any other changes I need to make. Actually, Jakub suggestion is a lot better. Using HOME=/tmp is really fine in tiny subset of occasions, and depends on what the program does and how.
Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]
Hi Gianfranco,
First of all, I apologize for the mix-up. I wasn't paying very close
attention to who was sending the emails. I think I've got it all
straightened out now :)
As described below, I've made the changes you requested and made the
adjustment for observing TMPDIR as Mattia suggested. Please let me know
if you have any further questions or if there are any other changes I
need to make.
Thanks again for taking a look at this.
- Nathan
On 2016-05-24 01:28 AM, Mattia Rizzolo wrote:
On Mon, May 23, 2016 at 08:37:46PM -0700, Nathan Osman wrote:
I apologize for not getting back to you sooner. I completely forgot to reply
to your last email.
Well, it was not mine, it was from Gianfranco.
I removed the debug package, bumped the standards version, and removed the
Lintian override. As for the test suite, I was able to reproduce the failure
and found the cause of the problem: the test suite expects the $HOME
environment variable to be set to a valid directory. 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.
I'll let Gianfranco check it again, but anyway, for the bit of setting
HOME to /tmp, please also respect TMPDIR¹. So, if TMPDIR is set, you
should do HOME=${TMPDIR:-/tmp} (bash syntax).
¹ https://en.wikipedia.org/wiki/TMPDIR
Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]
Hi Mattia, I apologize for not getting back to you sooner. I completely forgot to reply to your last email. I removed the debug package, bumped the standards version, and removed the Lintian override. As for the test suite, I was able to reproduce the failure and found the cause of the problem: the test suite expects the $HOME environment variable to be set to a valid directory. 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. The latest changes have been uploaded to mentors: https://mentors.debian.net/package/qhttpengine - Nathan On 2016-05-23 02:12 AM, Mattia Rizzolo wrote: Hi Nathan! On Fri, Apr 01, 2016 at 07:51:22PM +, Gianfranco Costamagna wrote: control: owner -1 ! control: tags -1 moreinfo Did anything happened here in the past 1,5 months? Are you still interested in getting this into Debian?
Bug#811564: ITP: nitroshare -- Cross-platform network file transfer application
Package: wnpp Severity: wishlist Owner: Nathan Osman * Package name: nitroshare Version : 0.3.0 Upstream Author : Nathan Osman * URL : https://github.com/nitroshare/nitroshare-desktop * License : MIT Programming Lang: C++ Description : Cross-platform network file transfer application NitroShare is designed to make transferring any file to any device as painless as possible. Network discovery is completely automatic, allowing files and entire directories to be instantly transferred to any other device on the network running the application.
Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qhttpengine" * Package name: qhttpengine Version : 0.1.0+dfsg1-1 Upstream Author :Nathan Osman * URL :https://github.com/nitroshare/qhttpengine * License : MIT Section : libs It builds those binary packages: libqhttpengine-dbg - HTTP server for Qt applications - debug info libqhttpengine-dev - HTTP server for Qt applications - development files libqhttpengine-doc - HTTP server for Qt applications - documentation libqhttpengine-examples - HTTP server for Qt applications - examples libqhttpengine0 - HTTP server for Qt applications To access further information about this package, please visit the following URL: http://mentors.debian.net/package/qhttpengine Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/q/qhttpengine/qhttpengine_0.1.0+dfsg1-1.dsc More information about qhttpengine can be obtained fromhttps://github.com/nitroshare/qhttpengine. Regards, Nathan Osman
Bug#811426: RFS: golang-github-kennygrant-sanitize/1.0-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "golang-github-kennygrant-sanitize" * Package name: golang-github-kennygrant-sanitize Version : 1.0-1 Upstream Author : Kenny Grant * URL : https://github.com/kennygrant/sanitize * License : BSD Section : devel It builds those binary packages: golang-github-kennygrant-sanitize-dev - Functions for sanitizing text in golang strings To access further information about this package, please visit the following URL: http://mentors.debian.net/package/golang-github-kennygrant-sanitize Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/golang-github-kennygrant-sanitize/golang-github-kennygrant-sanitize_1.0-1.dsc More information about sanitize can be obtained from https://github.com/kennygrant/sanitize. Regards, Nathan Osman
Bug#811224: ITP: qhttpengine -- HTTP server for Qt applications
Package: wnpp Severity: wishlist Owner: Nathan Osman * Package name: qhttpengine Version : 0.1.0 Upstream Author : Nathan Osman * URL : https://github.com/nitroshare/qhttpengine * License : MIT Programming Lang: C++ Description : HTTP server for Qt applications A collection of classes that allow Qt applications to provide an embedded HTTP server. QHttpEngine supports both serving static files from a directory and exposing slots in a QObject-derived class as methods in a public API. Extensive documentation and examples are included. Debian packaging is available here: https://github.com/nitroshare/qhttpengine-debian I am looking for a sponsor for this package and I am willing to be the maintainer.
Bug#810955: ITP: golang-github-kennygrant-sanitize -- Functions for sanitizing text in golang strings
I completely forgot to mention that I have already created Debian packaging for the library and put it on Launchpad. You can view the source code here[1] or check out the branch with Bazaar using: bzr branchlp:~hectane/hectane/golang-github-kennygrant-sanitize-debian The Debian package is released under the MIT license but since I am the author, I can release it under another FOSS license if it makes things any easier. [1]: http://bazaar.launchpad.net/~hectane/hectane/golang-github-kennygrant-sanitize-debian/files
Bug#810955: ITP: golang-github-kennygrant-sanitize -- Functions for sanitizing text in golang strings
Package: wnpp Severity: wishlist Owner: Nathan Osman * Package name: golang-github-kennygrant-sanitize Version : 1.0 Upstream Author : Kenny Grant * URL : https://github.com/kennygrant/sanitize * License : BSD Programming Lang: Go Description : Functions for sanitizing text in golang strings Provides functions that replace or remove characters from strings that contain HTML or non-ASCII characters, allowing the string to be used where plaintext or safe filenames are expected. I am looking for a sponsor for this package and I am willing to be the maintainer.
Bug#805517: golang: Panic when running go_test:runtime and go_test:cmd/go tests
Source: golang Version: 1.5.1-4 Severity: normal Dear Maintainer, I am attempting to build the Go 1.5.1 package on my Raspberry Pi model B. This device has a 700 MHz ARMv6 CPU and 512 MB of RAM (384 MB usable after GPU split). Because the go_test:runtime and go_test:cmd/go tests are so extensive, the default timeout is reached, causing a panic. Thankfully, the timeout can be extended by setting the GO_TEST_TIMEOUT_SCALE environment variable. Therefore, I am attaching a small patch that sets this variable to 6, extending the timeout to 18 minutes (which seems to be enough for completing the tests). This variable is only set when compiling on ARM CPUs. (I'm also attaching the stack traces from the two panics.) -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) panic: test timed out after 6m0s goroutine 22548 [running]: testing.startAlarm.func1() /usr/lib/go/src/testing/testing.go:703 +0x10c created by time.goFunc /usr/lib/go/src/time/sleep.go:129 +0x34 goroutine 1 [chan receive, 5 minutes, locked to thread]: testing.RunTests(0x26209c, 0x309110, 0xa2, 0xa2, 0x1) /usr/lib/go/src/testing/testing.go:562 +0x618 testing.(*M).Run(0x1053bf7c, 0x125e8) /usr/lib/go/src/testing/testing.go:494 +0x6c main.main() runtime/_test/_testmain.go:904 +0x118 goroutine 22544 [syscall, 5 minutes]: syscall.Syscall6(0x72, 0x160a, 0x10538be8, 0x0, 0x105126e0, 0x0, 0x0, 0x158cb0, 0x158420, 0x8) /usr/lib/go/src/syscall/asm_linux_arm.s:48 +0x8 syscall.wait4(0x160a, 0x10538be8, 0x0, 0x105126e0, 0x50, 0x0, 0x0) /usr/lib/go/src/syscall/zsyscall_linux_arm.go:172 +0x64 syscall.Wait4(0x160a, 0x10538c0c, 0x0, 0x105126e0, 0x10538c74, 0x0, 0x0) /usr/lib/go/src/syscall/syscall_linux.go:256 +0x54 os.(*Process).wait(0x10f405e0, 0x3, 0x0, 0x0) /usr/lib/go/src/os/exec_unix.go:22 +0xcc os.(*Process).Wait(0x10f405e0, 0x10f40490, 0x0, 0x0) /usr/lib/go/src/os/doc.go:45 +0x2c os/exec.(*Cmd).Wait(0x10f6a5a0, 0x0, 0x0) /usr/lib/go/src/os/exec/exec.go:380 +0x1b4 os/exec.(*Cmd).Run(0x10f6a5a0, 0x0, 0x0) /usr/lib/go/src/os/exec/exec.go:258 +0x58 os/exec.(*Cmd).CombinedOutput(0x10f6a5a0, 0x0, 0x0, 0x0, 0x0, 0x0) /usr/lib/go/src/os/exec/exec.go:424 +0x2c8 runtime_test.executeTest(0x1054c480, 0x267d50, 0x3db, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) /home/pi/build/go/src/runtime/crash_test.go:88 +0xea0 runtime_test.TestCgoCallbackGC(0x1054c480) /home/pi/build/go/src/runtime/crash_cgo_test.go:46 +0x68 testing.tRunner(0x1054c480, 0x309200) /usr/lib/go/src/testing/testing.go:456 +0xa8 created by testing.RunTests /usr/lib/go/src/testing/testing.go:561 +0x5ec goroutine 22547 [syscall, 5 minutes]: syscall.Syscall(0x3, 0x4, 0x10f38600, 0x200, 0x54fc4, 0x200, 0x1bcad0) /usr/lib/go/src/syscall/asm_linux_arm.s:17 +0x8 syscall.read(0x4, 0x10f38600, 0x200, 0x200, 0x119570, 0x0, 0x0) /usr/lib/go/src/syscall/zsyscall_linux_arm.go:783 +0x78 syscall.Read(0x4, 0x10f38600, 0x200, 0x200, 0x0, 0x0, 0x0) /usr/lib/go/src/syscall/syscall_unix.go:160 +0x4c os.(*File).read(0x10520560, 0x10f38600, 0x200, 0x200, 0x10f38600, 0x0, 0x0) /usr/lib/go/src/os/file_unix.go:211 +0x54 os.(*File).Read(0x10520560, 0x10f38600, 0x200, 0x200, 0x46ac0, 0x0, 0x0) /usr/lib/go/src/os/file.go:95 +0x7c bytes.(*Buffer).ReadFrom(0x1054c540, 0xb6e4cbd8, 0x10520560, 0x0, 0x0, 0x0, 0x0) /usr/lib/go/src/bytes/buffer.go:173 +0x22c io.copyBuffer(0xb6e4cba8, 0x1054c540, 0xb6e4cbd8, 0x10520560, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) /usr/lib/go/src/io/io.go:375 +0x124 io.Copy(0xb6e4cba8, 0x1054c540, 0xb6e4cbd8, 0x10520560, 0x0, 0x0, 0x0, 0x0) /usr/lib/go/src/io/io.go:351 +0x64 os/exec.(*Cmd).writerDescriptor.func1(0x0, 0x0) /usr/lib/go/src/os/exec/exec.go:232 +0x98 os/exec.(*Cmd).Start.func1(0x10f6a5a0, 0x10f40480) /usr/lib/go/src/os/exec/exec.go:340 +0x1c created by os/exec.(*Cmd).Start /usr/lib/go/src/os/exec/exec.go:341 +0x840 SIGQUIT: quit PC=0x279c24 m=0 goroutine 238 [syscall]: syscall.Syscall(0x3, 0x4, 0x10d93000, 0x200, 0x55844, 0x200, 0x3fea70) /usr/lib/go/src/syscall/asm_linux_arm.s:17 +0x8 fp=0x10b28600 sp=0x10b285fc syscall.read(0x4, 0x10d93000, 0x200, 0x200, 0x141568, 0x0, 0x0) /usr/lib/go/src/syscall/zsyscall_linux_arm.go:783 +0x78 fp=0x10b28620 sp=0x10b28600 syscall.Read(0x4, 0x10d93000, 0x200, 0x200, 0x0, 0x0, 0x0) /usr/lib/go/src/syscall/syscall_unix.go:160 +0x4c fp=0x10b28640 sp=0x10b28620 os.(*File).read(0x10cbefd8, 0x10d93000, 0x200, 0x200, 0x10d93000, 0x0, 0x0) /usr/lib/go/src/os/file_unix.go:211 +0x54 fp=0x10b28660 sp=0x10b28640 os.(*File).Read(0x10
Bug#691467: ITP: qenet -- Qt classes for interfacing with the ENet library
Package: wnpp Severity: wishlist Owner: Nathan Osman * Package name: qenet Version : 0.1 Upstream Author : Nathan Osman * URL : https://launchpad.net/qenet * License : LGPL-3 Programming Lang: C++ Description : Qt classes for interfacing with the ENet library. This library is essentially a C++ wrapper for the ENet library. The library contains a set of classes that make it easy to integrate ENet into existing Qt projects, making use of native Qt types and providing both signals and slots where appropriate. The library ships with complete documentation, two example applications, and a set of unit tests. To make things (hopefully) easier, I have created Debian packaging for this package in a Bazaar branch over here: https://code.launchpad.net/~george-edison55/qenet/debian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
