Bug#899349: general: USB mouse disconnects and is reconnected every minute
Package: general Severity: normal Dear Maintainer, After 1 minute of inactivity on TTY1 appear this messages. Mouse is: Logitech M100. Aug 18 00:20:41 localhost kernel: [ 64.225557] usb 1-1.4: new low speed USB device number 4 using ehci_hcd Aug 18 00:20:41 localhost kernel: [ 64.316417] input: Genius Optical Mouse as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input9 Aug 18 00:20:41 localhost kernel: [ 64.316473] generic-usb 0003:0458:003A.0002: input,hidraw0: USB HID v1.11 Mouse [Genius Optical Mouse] on usb-:00:1a.0-1.4/input0 Aug 18 00:21:41 localhost kernel: [ 124.261211] usb 1-1.4: USB disconnect, device number 4 Aug 18 00:21:43 localhost kernel: [ 125.722315] usb 1-1.4: new low speed USB device number 5 using ehci_hcd Aug 18 00:21:43 localhost kernel: [ 125.813042] input: Genius Optical Mouse as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input10 Aug 18 00:21:43 localhost kernel: [ 125.813100] generic-usb 0003:0458:003A.0003: input,hidraw0: USB HID v1.11 Mouse [Genius Optical Mouse] on usb-:00:1a.0-1.4/input0 Aug 18 00:22:43 localhost kernel: [ 185.756780] usb 1-1.4: USB disconnect, device number 5 Aug 18 00:22:45 localhost kernel: [ 187.219082] usb 1-1.4: new low speed USB device number 6 using ehci_hcd Aug 18 00:22:45 localhost kernel: [ 187.309663] input: Genius Optical Mouse as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input11 Aug 18 00:22:45 localhost kernel: [ 187.309722] generic-usb 0003:0458:003A.0004: input,hidraw0: USB HID v1.11 Mouse [Genius Optical Mouse] on usb-:00:1a.0-1.4/input0 Aug 18 00:23:45 localhost kernel: [ 247.252457] usb 1-1.4: USB disconnect, device number 6 Aug 18 00:23:46 localhost kernel: [ 248.712302] usb 1-1.4: new low speed USB device number 7 using ehci_hcd Aug 18 00:23:46 localhost kernel: [ 248.803287] input: Genius Optical Mouse as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input12 Aug 18 00:23:46 localhost kernel: [ 248.803343] generic-usb 0003:0458:003A.0005: input,hidraw0: USB HID v1.11 Mouse [Genius Optical Mouse] on usb-:00:1a.0-1.4/input0 Aug 18 00:24:47 localhost kernel: [ 308.748075] usb 1-1.4: USB disconnect, device number 7 -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU:ru (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Removing packages perhaps too aggressively?
On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote: > GnuCash removed from testing in August 2017 Depends on obsolete WebKit version (fixed in experimental): https://tracker.debian.org/pkg/gnucash https://tracker.debian.org/news/859896/gnucash-removed-from-testing/ https://bugs.debian.org/790204 > FreeCad removed from testing in October 2017 https://tracker.debian.org/pkg/freecad https://tracker.debian.org/news/881598/freecad-removed-from-testing/ https://bugs.debian.org/784512 > no sign of any effort to readd them in sight ... This is incorrect: gnucash 3.0 looks like it will return to testing at some point. FreeCAD upstream is porting to Qt5 via PySide2: https://forum.freecadweb.org/viewtopic.php?t=14999 -- bye, pabs https://wiki.debian.org/PaulWise
Bug#899322: ITP: trace2dbest -- bulk submission of chromatogram data to dbEST
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: trace2dbest Version : 3.0.1 * URL : http://www.nematodes.org/bioinformatics/trace2dbEST/ * License : GPL Programming Lang: Perl Description : bulk submission of chromatogram data to dbEST To appear on https://salsa.debian.org/med-team/trace2dbest ESTs are short sequences derived from reverse-transcribed RNA. Their abundances yield insights in the expression of genes across tissues, support the discovery of new genes and allow to assess the coverage of whole genome sequencing projects. Public databases like dbEST at the NCBI collect this data. . trace2dbEST process raw sequenceing chromatograph trace files from EST projects into quality-checked sequences, ready for submission to dbEST. trace2dbEST guides you through the creation of all the necessary files for submission of ESTs to dbEST. trace2dbest makes use of other software (available free under academic licence) that you will need to have installed, namely phred, cross_match and (optionaly) BLAST.
Re: Explaining Debian's approach to QA
Hi, On 22-05-18 12:35, Simon McVittie wrote: > We'd have better test > coverage if packages could rely on being able to run tests in a qemu > virtual machine.) Just for the record, it seems possible (albeit somebody needs to do some work) to enable ci.d.n to run VM's: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834572#25 Help or somebody driving this is welcome. Paul signature.asc Description: OpenPGP digital signature
Re: Explaining Debian's approach to QA
On Sun, 20 May 2018 at 19:26:22 +, Jose Miguel Parrella Romero wrote: > Of course, for folks that live in a CI/CD environment where the build > log and the stop light are the vehicles of accountability, the concept > of a piuparts run happening after you've uploaded and getting a bug > report that you then go address and "start over" is almost foreign to them. I think Paul Gevers' point about the primary QA gate being between unstable and testing is a key insight here. Another factor is that the most complete possible set of QA checks is too slow to be something that we can expect maintainers to run before uploading to unstable. If you build for amd64 and i386 (for multiarch co-installability), do a separate architecture-independent build (because that's what the production buildds do), run build-time tests, run autopkgtests, and run piuparts, then preparing, installing and smoke-testing an upload can take hours of processing (and if it fails, you get to start again). I do that for dbus, but it's far too slow to be something I would be comfortable with requiring all maintainers to do, and simultaneously not as thorough as it could be. In principle there are more checks that I ought to be doing, like running autopkgtest in LXC as well as in qemu (because maybe the tests will fail in that more restrictive environment) or running dependent packages' autopkgtests (which could take multiple days for a heavily-used package like dbus, systemd or python) - but I have to balance "test the new release thoroughly" against "get a release out in a finite time". The longer it takes me to do a complete release, the fewer occasions there are when I have enough uninterrupted time to do one. If we had more machines running CI/CD tests against VCS repositories, then maybe I could commit a release candidate to salsa.debian.org, let the tests run, and come back hours or days later to tag a release - but that isn't going to work if what I'm releasing is an embargoed security fix that needs to be kept confidential until release time. (We also don't currently have enough Gitlab CI runners for everyone to run tests on them, and not every package's tests can be run in the Docker containers used on salsa.debian.org or the LXC containers used on ci.debian.net: anything that plays with namespaces, containers and mount points, like bubblewrap, flatpak and debootstrap, is going to run into limitations around nested containers, which don't work because they are difficult or impossible to provide securely. We'd have better test coverage if packages could rely on being able to run tests in a qemu virtual machine.) smcv
Re: Removing packages perhaps too aggressively?
On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote: > Just stumbled over some removals: > > GnuCash removed from testing in August 2017 > FreeCad removed from testing in October 2017 > > no sign of any effort to readd them in sight ... Maybe you are looking in a wrong place. Last gnucash upload was in April. > The point here is "interested maintainer". I concur it would have been > easy to bring them back, but it did not happen. It's easy to make guesses, it's harder to do the actual work. But you can easily improve your guesses by researching the reasons packages are removed from testing. -- WBR, wRAR signature.asc Description: PGP signature
Re: Removing packages perhaps too aggressively?
Just stumbled over some removals: GnuCash removed from testing in August 2017 FreeCad removed from testing in October 2017 no sign of any effort to readd them in sight ... > Debian is meant to be a high-quality operating system, not a collection > of packages that we keep around in case they come in useful one day. Those packages above are useful today, they even mark the most advanced programs in their respective domain > If a removed package later turns out to be useful or desirable, we have > plenty of opportunities for an interested maintainer to bring it back, > and a couple of ways (archive.debian.org, snapshot.debian.org) for a > user to install it locally. The point here is "interested maintainer". I concur it would have been easy to bring them back, but it did not happen. Depleting the next stable release from highly productive packages seems not the most sensible approach to me ... jm2c Heinz
