Bug#1007106: reportbug: please make the meaning of the a11y tag clearer
On 3/14/22, john doe wrote: > On 3/14/2022 12:53 AM, Samuel Thibault wrote: >> Hello, >> >> Simon McVittie wrote: >>> Can anyone suggest a wording that makes the intention of the tag >>> clearer, >>> without "othering" the people who particularly need bugs with this tag >>> to >>> be fixed? I've cc'd debian-accessibility in the hope that someone on >>> that >>> list has a better idea. >> >> Thanks for the notice! >> >>> 1 a11y This bug is relevant to the accessibility of the package. >> >> Perhaps simply adding >> >> 1 a11y This bug is relevant to the accessibility of the package for >> disabled users. >> >> ? >> >> Or rephrasing to make it shorter: >> >> 1 a11y This bug affects disabled users. >> > > Or an alternative: > > 1 a11y This tag refers to peoples with disabilities > > Would be nice if native English speakers could help properly phrasing > this! :) ... affects people with disabilities. ... affects users with disabilities. It's called "person (or people) first language" where self-advocates ask to be recognized first before their disability. Dear friends in Atlanta, Georgia, and elsewhere were instrumental in helping it gain traction exactly when the following acknowledges as a date of reference: https://odr.dc.gov/page/people-first-language And I just learned something new k/t this thread. There is also "identity first language" that understandably evolved as a result: https://accessate.net/features/2519/person-first-vs-identity-first-language My takeaway is "users with disabilities" remains an accepted, respectful umbrella for all disabilities. If this was only about one specific disability, there may be an alternative that each disability has voiced is preferable to them. Of note: There are times when it's tough to fulfill "person first" fully due to the limitations of e.g. social media's occasional 280-character limitations per post. Cindy :) -- * runs with birdseed *
Bug#825036: apt-show-versions: Can't create/no such file at /usr/bin/apt-show-versions
Package: apt-show-versions Version: 0.22.12 Followup-For: Bug #825036 Dear Maintainer, Hi! I started to report this a few weeks ago then got sidetracked. The issue was fixed by simply reinstalling, but now it's showing up again on one of my maybe 4 Debian Bullseye debootstrap installs. Of note, I haven't used this package in a couple years. I install it as a fan favorite kind of thing to show support since it was a huge help when I was newer at personalizing Debian. Also of note is that I wasn't familiar with how some portion of apt-show-versions gets deleted and then refreshed (?). When this occurred a few weeks ago, I had an install that hadn't been upgraded yet. It still had its /var/cache/apt-show-versions directory where that entire directory was missing from the other installs that were hitting this failure. This is the error message that kicks out at the end of "apt-get update": BEGIN APT-GET UPDATE APT-SHOW-VERSIONS ERROR can't create /var/cache/apt-show-versions/files: No such file or directory at /usr/bin/apt-show-versions line 197. Reading package lists... Done E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i' E: Sub-process returned an error code END APT-GET UPDATE APT-SHOW-VERSIONS ERROR Today I "cognitively" caught the reference to /usr/bin/apt-show-versions. Shortest take on that possible is to ask... could Debian's move toward symlinking /bin and /sbin, etc, have something to do with this? Yes, I see this bug is 2016, but still.. maybe something even back then was already in progress regarding symlinks. Am asking because a few years ago, my debootstrap installs' root users all started whining, "I HAVE NO NAME!" By some miracle, I was able to make a connection that symlinking a HUGE previously downloaded packages hoard to /var/cache/apt/archives was the culprit. The fix for that was to "mount -B" the same hoard to /apt/archives instead. That issue hasn't reoccurred since I made that "mount -B" switch. In the interest of fairness that a user deviance could be a potential trigger, this following error was also thrown today. This text appears in full in between the "Reading package lists" and "Problem executing scripts" lines: BEGIN SIGNAL ERROR W: GPG error: https://updates.signal.org/desktop/apt xenial InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D980A17457F6FB06 E: The repository 'https://updates.signal.org/desktop/apt xenial InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. END SIGNAL ERROR What that's telling me, the (deviant) User, is that I rsync'ed that particular instance of Bullseye. In the process, I forgot to take the final, appropriate "wget -O- | apt-key add" vendor trust step. Yes, I know, third party. Never used it, just installed because it was potentially going to be used by a group whose advocacy I was going to support. I can't remember if that error was thrown the other several times this happened a few weeks ago. Signal's not installed on all of my Bullseye partitions BECAUSE I haven't used it. I'm just thinking that MAYBE its failure as *that one, singular product's method of failing* somehow stops something else from occurring. In other words, one step might be to make sure it's not touching something it shouldn't be touching when it fails. Lastly, these were what I was going to send when I first encountered this a few weeks ago. These are from my history.log and reflect the last two Bullseye "apt-get upgrade" actions performed just before this apt-show-versions error originally occurred. Both are included because I figure it could either be that the dust settled on the 2021.05.26 upgrade (via reboot) and maybe caused this, OR the glitch could have also already registered while the 2021.05.28 upgrade was still actively in progress and not yet completed. 2021.05.26 APT-GET UPGRADE FOR BULLSEYE Upgrade: iwd:amd64 (1.12-1, 1.14-3), libgtk2.0-bin:amd64 (2.24.33-1, 2.24.33-2), libgail18:amd64 (2.24.33-1, 2.24.33-2), libgtk2.0-common:amd64 (2.24.33-1, 2.24.33-2), libgtk2.0-0:amd64 (2.24.33-1, 2.24.33-2), xfig:amd64 (1:3.2.8-2, 1:3.2.8-3), gtk2-engines-pixbuf:amd64 (2.24.33-1, 2.24.33-2), xfig-libs:amd64 (1:3.2.8-2, 1:3.2.8-3), libgail-common:amd64 (2.24.33-1, 2.24.33-2) 2021.05.28 APT-GET UPGRADE FOR SAME BULLSEYE INSTALL Upgrade: libxml2-dev:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), libxml2-utils:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), opera-stable:amd64 (76.0.4017.123, 76.0.4017.154), libxml2:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7), python3-yaml:amd64 (5.3.1-3+b1, 5.3.1-4), python3-libxml2:amd64 (2.9.10+dfsg-6.6, 2.9.10+dfsg-6.7) That's all I can think of right now. Hope
Bug#931851: pysolfc: pythonfc fails to start since python upgrades, new version with fix available upstream
Package: pysolfc Version: 2.0-4 Followup-For: Bug #931851 Dear Maintainer(s), Hi! Thank you all so much for an embarassing number of hours of game playing enjoyment, primarily k/t Balarama, Mahjongg, and Freecell. Am writing just to confirm that I also experienced what appears to be the exact same failure to start as defined in original bug report. After pysolfc failed a couple times via the Applications menu route, I, too, attempted to start it via the terminal command line. My instance's command line failure feedback appears to read exactly the same. Version is current and newly installed via a Debian Bullseye testing debootstrap just a few days ago. Basically the only difference I'm seeing is that I most likely would not have been able to determine this was about a change in Python had I filed the initial bug. Kudos @ Heinz for being able to supply that critically important detail. :) Thank you all again! Cindy Sue Causey Talking Rock, Pickens County, Georgia USA * runs with birdseed * -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pysolfc depends on: ii python2.7.16-1 ii python-configobj 5.0.6-3 ii python-pygame 1.9.4.post1+dfsg-3 ii python-tk 2.7.16-2 Versions of packages pysolfc recommends: ii python-pil.imagetk [python-imaging-tk] 6.1.0-1 pn tk-tile Versions of packages pysolfc suggests: pn freecell-solver-bin pn pysolfc-cardsets -- no debconf information
Bug#929167: apt: Failed to confirm additional package to be installed (Ref: curl)
Package: apt Version: 1.8.1 Severity: important Dear Maintainer(s), Hi! #ThankYou for all the work you all do! Once I found the apt-get/apt command line family method of managing Debian packages, I've never looked back since. Why I'm writing: Odd glitch this morning. While *attempting* to read through and comprehend the current reportbug APT buglist entries before sending this, it occurred to me that this glitch could potentially be abused if someone figured out how it occurred. I've marked this bug as "important", but... I feel it's possibly a security risk on some level... So what had happened was: This morning, I ran "apt upgrade" (which is occasionally alternated with apt-get purely because that's where my Fingertips go). I'm on dialup so I have to cherry pick what packages get upgraded in between any other online computing. This morning I started with "curl". Curl needed two packages to install. Those packages only added up to 595KB download size, but THAT FAILED *because* of dialup. That's the GOOD NEWS because it provided the opportunity to witness the following issue.. Run #1 began like this: + START APT FEEDBACK FOR RUN #1 + The following additional packages will be installed: libcurl4 The following packages will be upgraded: curl libcurl4 2 upgraded, 0 newly installed, 0 to remove and 19 not upgraded. Need to get 595 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://distro.ibiblio.org/debian buster/main amd64 curl amd64 7.64.0-3 [264 kB] + END APT FEEDBACK FOR RUN #1 + Boom, right into the download process without asking after encountering a secondary package that needed to be simultaneously installed. APT completely skipped over the *expected* "Do you want to continue? [Y/n]" line which SHOULD HAVE been triggered by APT needing to install that additional "libcurl4" package. APT instead immediately began the "curl/libcurl4" package combination upgrade without further intervention from me. On the second run that was necessary because the dialup connection failed, APT reverted back to the expected behavior for that SAME package, i.e.: + START APT FEEDBACK FOR RUN #2 + The following additional packages will be installed: libcurl4 The following packages will be upgraded: curl libcurl4 2 upgraded, 0 newly installed, 0 to remove and 19 not upgraded. Need to get 331 kB/595 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] + END APT FEEDBACK FOR RUN #2 + The real time outcome of what occurred is that APT caught itself in Run #2 and recovered thus reverting back to its expected behavior as usual. That expected behavior is where it asks first before forging ahead with the installation of more necessary dependency or primary packages than users initially enter on the command line. A "conspiracy leaning" outcome of what occurred would potentially be: If someone figures out how to maliciously trigger that behavior via a package not directly under Debian Developers' scrutiny, there is *THEORETICALLY* a chance that behavior could be abused to infiltrate a potentially vulnerable system. As for me, I ALWAYS look at what apt/apt-get's additionally installing just to make sure all packages are recognizable as familiar k/t years of having to upgrade via this manual method. New users and very busy seasoned users using much faster network connections don't always have that.. *cough*.. LUXURY. :) That's pretty much all I can think of to fill in. Thank you all again for what became a very user-friendly method of maintaining Debian once I got over the *fear* of doing anything via Linux command line. Afterthought: For anyone who stumbles upon this and has not yet done so, I highly recommend at least test-driving that route by working with a very simple package (and the guidance of your favorite user support list). APT's a very *EMPOWERING* alternative once you get the hang of it! :) Cindy Sue in Talking Rock :) * runs with birdseed * -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.18\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-3-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.18\.0-3-amd64$";
Bug#887022: xfce4-clipman: History vanishes on reboot
Package: xfce4-clipman Version: 2:1.4.1-1 Severity: important Dear Maintainer, Dear Maintainer, First and as always, #ThankYOU for the work you do!! Now for the *potential* bug: I don't know when this started occurring. I copy and paste so many things that it could have been existing for a while, and I'd never know because Xfce4-Clipman is always already quite full when I need to use it, grin. Expected behavior *for me* is that CTRL+C history remain viable from one reboot to the next. I *thought* it used to do that at some point, but it's possible I'm confusing it with something else. Just now I right clicked over its icon and quickly found an option to toggle being able to save current history upon *QUIT*. I do see the distinction between manually shutting it down versus letting it have its own mind when rebooting. My potentially naive expectation is that Xfce4-Clipman would retain a current session's history without the further intervention of having to remember to shut it down just before rebooting. That expectation is primarily because Xfce4-Clipman works so *visually* silent in the background that shutting it down is easy to overlook as a checkpoint just prior to rebooting. For the record k/t many years of experience, I do, yes, know well, sometimes quite painfully, grin, how many, if not most, clipboards working behind the scenes notoriously purge on reboots. To that end, you're welcome to shift this over to a wish list item if it seems more appropriate k/t Xfce4-Clipman's history of design and intended features. If you go that route, something just occurred to me For *me*, it would be nice to have Xfce4-Clipman *ask* if I want to save a current session's history just prior to rebooting. Just as many things do, that could be... something that could be toggled on and off just as QUIT is now. In a perfect World, Xfce4-Clipman could provide the opportunity to have a popup "save or don't to save" message the way some other programs do. Existing example is how a browser just halted being closed down while it waited for me to decide "yes or no" if I wanted to close down one tab of many where I had started to write a message that was never completed and sent. Thank you again. Best wishes in all you do! PS I'll try to remember to manually shut it down for the next reboot in the next few days. If it does *not* retain history then, I'll come back and update. I anticipate that I will probably not have to update in that case. :) PPS Reportbug proffered that there are potential updates available, BUT those are from testing and unstable. What I will do is... leave it as is for the next reboot when I hope to remember to use QUIT first. For some reboot after that, I'll try to THEN remember to test the other releases' versions to see how they handle for the above. That crosses into that whole mixing and matching between releases which starts that snowball rolling of having to update other packages/dependencies, too, but who knows, maybe something will come of it. I'm game. The fix is always only one backup or new debootstrap installation away. :) Cindy Sue Causey Talking Rock, Pickens County, Georgia * runs with duct tape * -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-clipman depends on: ii libc6 2.24-11+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u1 ii libglib2.0-02.50.3-2 ii libgtk-3-0 3.22.11-1 ii libqrencode33.4.4-1+b2 ii libx11-62:1.6.4-3 ii libxfce4ui-2-0 4.12.1-2 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii libxtst62:1.2.3-1 xfce4-clipman recommends no packages. xfce4-clipman suggests no packages. -- no debconf information
Bug#875806: RFS: tetzle/2.1.1+dfsg1-1 (adopted orphaned package)
On 9/14/17, Innocent De Marchi <tangram.pe...@gmail.com> wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "tetzle" > > * Package name: tetzle >Version : 2.1.1+dfsg1-1 >Upstream Author : Graeme Gott <gra...@gottcode.org> > * URL : https://gottcode.org/tetzle/ > * License : GPL-3 >Section : games > > It builds those binary packages: > > tetzle - Jigsaw puzzle game > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/tetzle > > > Alternatively, one can download the package with dget using this > command: > > dget -x > > https://mentors.debian.net/debian/pool/main/t/tetzle/tetzle_2.1.1+dfsg1-1.dsc > > The package is also in git (collab-maint) > https://anonscm.debian.org/git/collab-maint/tetzle.git Congratulations (from a Dev wannabe)! I'm envious. I've used this puzzle for a few years. There's been a very notable change recently, including that it worked successfully on Buster/Testing. *yayhoo!* Just writing to say if you ever find a minuscule task that you wouldn't mind "pawning off" on someone else, I'd like to *finally* learn on this one, if not one similar to it. I'd found it a while back in orphaned packages, but #Life kept getting in the way of learning more about how to work with it. I'll be *very happily* following (aka lurking) your locations above in hopes of picking up something by osmosis, grin. Have fun! :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#862866: upgrade-reports: Error message after installation/Upgrade (Synaptic)
My apologies. I literally "hate" when I have to respond to myself as fast as I send an email. An important detail I left off is that this occurs for me while using apt-get. And typo correction attached below where "directly" should have been "directory". *oops!* :) On 5/18/17, Cindy-Sue Causey <butterflyby...@gmail.com> wrote: > On 5/17/17, Bill Allombert <ballo...@debian.org> wrote: >> On Wed, May 17, 2017 at 11:36:50PM +0300, Geo Pe wrote: >>> Package: upgrade-reports >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> *** Reporter, please consider answering these questions, where >>> appropriate >>> *** >>> >>>* What led up to the situation? >>> I upgraded from stable to testing. Try to install/upgrade various >>> packages >>> >>>* What exactly did you do (or not do) that was effective (or >>> ineffective)? >>> Tried to install netbeans. The problem is repeaded with other packages. >>>* What was the outcome of this action? >>> Netbeans was installed but i got the following message after >>> installation: >>> >>> "W: Download is performed unsandboxed as root as file >>> '/var/cache/apt/archives/partial/libminizip1_1.1-8+b1_amd64.deb' >>> couldn't >>> be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)" >>> >>>* What outcome did you expect instead? >>> Message for successfull installation. >> >> Hello Geo Pe, >> This is not an error but a warning (W: mean warning). >> You should check the permission of >> /var/cache/apt/archives/partial/ >> >> Cheers, >> -- >> Bill. <ballo...@debian.org> >> >> Imagine a large red swirl here. > > > I've received that warning in the past. There obviously could be > multiple causes for seeing it. In my case and purely discovered by > accident, the warning occurred because I had symlinked to > '/var/cache/apt/archives which was on an external hard drive. > > No matter where the target '/var/cache/apt/archives/ was placed in a > data'esque hierarchy on that external hard drive, I still received > that error. Permissions *appeared* to be correct, but that also didn't > seem to make a difference. > > As a matter of record as long as the topic is here, that symlinking > also caused my debootstrap chroot user "root" to have an identity > crisis where it kept yelling, "I Have No Name!" > > As soon as I removed the symlink to '/var/cache/apt/archives/ and > moved files back in the primary hierarchy, debootstrap's chroot user > root found itself again as "root". If I'm remembering correctly, that > instance was ultimately traced back to my missing a similar > permissions denied warning early on in debootstrap. That warning > disappeared immediately upon removal of the package archives [directory] > symlink. > > Hope this some day helps somehow.. > > Cindy :) > > -- > Cindy-Sue Causey > Talking Rock, Pickens County, Georgia, USA > > * runs with duct tape *
Bug#862866: upgrade-reports: Error message after installation/Upgrade (Synaptic)
On 5/17/17, Bill Allombert <ballo...@debian.org> wrote: > On Wed, May 17, 2017 at 11:36:50PM +0300, Geo Pe wrote: >> Package: upgrade-reports >> Severity: normal >> >> Dear Maintainer, >> >> *** Reporter, please consider answering these questions, where appropriate >> *** >> >>* What led up to the situation? >> I upgraded from stable to testing. Try to install/upgrade various >> packages >> >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> Tried to install netbeans. The problem is repeaded with other packages. >>* What was the outcome of this action? >> Netbeans was installed but i got the following message after >> installation: >> >> "W: Download is performed unsandboxed as root as file >> '/var/cache/apt/archives/partial/libminizip1_1.1-8+b1_amd64.deb' couldn't >> be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)" >> >>* What outcome did you expect instead? >> Message for successfull installation. > > Hello Geo Pe, > This is not an error but a warning (W: mean warning). > You should check the permission of > /var/cache/apt/archives/partial/ > > Cheers, > -- > Bill. <ballo...@debian.org> > > Imagine a large red swirl here. I've received that warning in the past. There obviously could be multiple causes for seeing it. In my case and purely discovered by accident, the warning occurred because I had symlinked to '/var/cache/apt/archives which was on an external hard drive. No matter where the target '/var/cache/apt/archives/ was placed in a data'esque hierarchy on that external hard drive, I still received that error. Permissions *appeared* to be correct, but that also didn't seem to make a difference. As a matter of record as long as the topic is here, that symlinking also caused my debootstrap chroot user "root" to have an identity crisis where it kept yelling, "I Have No Name!" As soon as I removed the symlink to '/var/cache/apt/archives/ and moved files back in the primary hierarchy, debootstrap's chroot user root found itself again as "root". If I'm remembering correctly, that instance was ultimately traced back to my missing a similar permissions denied warning early on in debootstrap. That warning disappeared immediately upon removal of the package archives directly symlink. Hope this some day helps somehow.. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#859926: speechd-up: fails to install
On 4/18/17, Paul Gevers <elb...@debian.org> wrote: > Hi all, > > I don't know what to make of it, but when I first start the speechd-up > daemon by hand, then the init script succeeds (because it finds the > daemon already running). But now it comes, I then can stop and start the > daemon successfully, but only when I am quick enough. This is > reproducible, sleep 4 works always, sleep 5 always fails (so far). > > paul@testavoira ~/ $ sudo /sbin/start-stop-daemon --start --nicelevel 0 > --quiet --oknodo --chdir "/" --exec "/usr/bin/speechd-up" --oknodo > --pidfile "/var/run/speechd-up.pid" -- -l1 > [Tue Apr 18 21:46:42 2017] speechd: Configuration has been read from > "/etc/speechd-up.conf" > > paul@testavoira ~ $ sudo service speechd-up start > > paul@testavoira ~ $ sudo service speechd-up stop ; sleep 4 ; sudo > service speechd-up start > > paul@testavoira ~ $ sudo service speechd-up stop ; sleep 5 ; sudo > service speechd-up start > Job for speechd-up.service failed because the control process exited > with error code. > See "systemctl status speechd-up.service" and "journalctl -xe" for details. Some things have been snipped above while I hope I left enough of Paul's latest feedback to give it due Respect. :) Simultaneous in my inbox is a different bug about Synaptic possibly keeping Orca from operating while Synaptic is open. It's this Bug #859262. Synaptic "freezes Orca screen reader" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859262 Is something like that maybe a possibility? Seeing the word "Synaptic" also originally made me wonder if our *_CHOICE_* of package managers is affecting things somehow. In my case, I have neither Synaptic nor Orca open because I don't use those. I only use "apt-get" via terminal interface for my package management. One thing is that I still don't know how to actually test speechd-up's functionality. For now, all I know is that it appeared to have successfully, initially installed with no complaints (via "apt-get install speechd-up"). Another factor in my install attempt is that mine was a brand new install. There was no residual "clutter" of past installs that could potentially also be causing unknown complications. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#859926: speechd-up: fails to install
On 4/17/17, MENGUAL Jean-Philippe <mengualjean...@free.fr> wrote: > Hi, > > We're going to have a look, but here I cannot reproduce. On Stretch, I > install the package without problems. So I am surprised. I may have > systemd-sysv, indeed, but not much more. > Hi.. I follow accessibility lists and thought I recognized this as a topic of theirs so I'm "playing along" to finally learn a little more about it. I was able to install speechd-up successfully, BUT I have no idea if it's functional because I don't know how to use it. I'm on a super basic debootstrap'ed Stretch with Xfce4 as my primary desktop environment. I've got Fluxbox and something else small that I've forgotten because I haven't switched around between them in a while. All of this is being provided in case it somehow helps explain why it's working for some of us and not for others. About the only programs I have are: Libreoffice, GIMP, Inkscape, Openshot, newly installed Piviti, Xine, and PySolFC (card games). For sound, aumix is my hero because I went almost a year without sound until I discovered that package. Others installed include GNOME ALSA mixer, Qas mixer, mpv video player. Seriously, I was desperate and downloading things that even remotely sounded like they might help trigger sound back on. Again, am mentioning all those because maybe they did something that triggered at least a successful install. Whether it actually works as intended or not, I have no clue aka literally clueless. As for systemd, I haven't touched a thing there. My system is whatever comes with a debootstrap install. I'm on a now older ASUS 10" where "uname -a" gets: Linux northpole 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux That's all I can think to write right now. :) > Le 16/04/2017 à 22:17, Paul Gevers a écrit : >> Hi >> >> On 16-04-17 21:51, Paul Gevers wrote: >>> I haven't figured out the difference yet. >> >> Probably somebody who knows systemd should have a look. I have the >> feeling it is interfering with the script and not doing what I read. >> >> I have no clue where to find the input (the service file?) that systemd >> is actually using yet. This is all new to me. #ThankYou for the work you all do! Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#838760: perl: Perl/Perl-base upgrade removes 141 packages (Sid/Unstable)
Package: perl Version: 5.22.2-5 Severity: critical Justification: breaks unrelated software Dear Maintainer, Hi! Thank you for all the hard work you all to so #poverty level folks have a chance to keep up with the tech world, too! As to why I'm writing, just tried to upgrade a select 30+ packages in Sid/Unstable. Apt-get is my chosen method to do so. Received the message that Received the advisement that: 2 upgraded, 2 newly installed, 141 to remove ALMOST let it happen because I was in a hurry and didn't immediately catch that message. Only thing I know to do in this kind of situation is to set Perl and Perl-base aside and wait for the next release so that's how I'm approaching it today. As a disclaimer that just came to mind, other important packages are not yet upgraded, as well. Those include cpp-6, libreoffice, linux-image-4.7.0-1-amd64, and linux-source-4.7. Reason is that I'm on dialup and am currently looking at approximately 400MB of upgrades that must be done incrementally. I always upgrade the smaller packages first. I figure that's important to know since each personally developed Debian system understandably succeeds and fails based on what's available within itself. The same attempt at 141 package removals occurs for both Perl and Perl-base but for now am only filing the bug against the primary "perl" unless you advise otherwise. Lastly, I didn't know if it was important for you to know which packages were affected so they are all included directly below. Thank you again *so much* for all you do. Happy Debian'ing!!! :) Cindy Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape* + + + BEGIN COPY OF APT-GET'S PERL UPGRADE ADVISEMENT + + + The following NEW packages will be installed: libperl5.24 perl-modules-5.24 The following packages will be REMOVED: apt-file apt-show-versions aspell aspell-en claws-mail claws-mail-i18n console-setup console-setup-linux debconf-i18n debsums dictionaries-common enchant gnome-user-guide hunspell-en-us inkscape keyboard-configuration libalgorithm-diff-xs-perl libapt-pkg-perl libb-hooks-endofscope-perl libcairo-perl libcgi-fast-perl libcgi-pm-perl libclass-accessor-perl libclass-xsaccessor-perl libclone-perl libcrypt-ssleay-perl libdata-alias-perl libdata-optlist-perl libemail-valid-perl libenchant1c2a libfcgi-perl libfile-fcntllock-perl libfile-fnmatch-perl libfile-libmagic-perl libgetopt-long-descriptive-perl libglib-perl libgtk2-gladexml-perl libgtk2-perl libgtkspell0 libgtkspell3-3-0 libhtml-form-perl libhtml-format-perl libhtml-parser-perl libhtml-tree-perl libimage-magick-perl libimage-magick-q16-perl libimport-into-perl libio-pty-perl libio-socket-inet6-perl libio-socket-ssl-perl libipc-run-perl liblist-moreutils-perl liblocale-gettext-perl liblwp-protocol-https-perl libmailtools-perl libmath-random-isaac-xs-perl libmime-tools-perl libmodule-implementation-perl libmodule-runtime-perl libmoo-perl libnamespace-clean-perl libnet-dbus-perl libnet-dns-perl libnet-smtp-ssl-perl libnet-ssleay-perl libossp-uuid-perl libpackage-stash-perl libpackage-stash-xs-perl libpango-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libparse-debianchangelog-perl libperlio-gzip-perl libscalar-list-utils-perl libsoap-lite-perl libsocket6-perl libsort-key-perl libsub-exporter-perl libsub-identify-perl libsub-name-perl libsvn-perl libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libunicode-utf8-perl libvariable-magic-perl libwebkit2gtk-4.0-37 libwebkit2gtk-4.0-37-gtk2 libwebkitgtk-3.0-0 libwww-perl libxml-parser-perl libxml-twig-perl libxmlrpc-lite-perl libyaml-libyaml-perl libyelp0 licensecheck lintian miscfiles modem-manager-gui moreutils packaging-dev piuparts qemu-launcher svn-buildpackage tasksel tasksel-data xombrero xorg xscreensaver xscreensaver-data xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-libinput xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-vmmouse xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-amdgpu xserver-xorg-video-ati xserver-xorg-video-cirrus xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nouveau xserver-xorg-video-openchrome xserver-xorg-video-qxl xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-savage xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-vesa xserver-xorg-video-vmware yelp + + + END COPY OF APT-GET'S PERL UPGRADE ADVISEMENT + + + -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin
Bug#822069: mousepad: CPU/disk usage may reflect extensive GLib/GTK* errors
Package: mousepad Version: 0.4.0-3 Followup-For: Bug #822069 Dear Maintainer, Hi again! Did not occur to me to look at ~/.xsession-errors one more time before submitting my own observations regarding these combined Mousepad bugs. That file, ~/.xsession-errors, was already in the 3,300,000 lines range by the time I submitted my report to you all. THEN I noticed that file was actively growing there in Thunar even as I sat there staring at its size (~200 MB). It was ticking upward a tenth (1/10th) of a megabyte every few seconds as I sat there watching. As noted in one or more of the related bugs, I had multiple windows open so I started closing them down. It was still ticking which caused me to notice I still had one more extra window open. The errors stopped replicating *the* second that last extra window was closed. The original single window is still open, but all is now quiet on the Mousepad front. :) Thank you again *so much*. Hope this was able to help somehow. Peace and best wishes from Talking Rock, Georgia! Cindy (Sue) :) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mousepad depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii libc62.22-7 ii libglib2.0-0 2.48.0-1 ii libgtk2.0-0 2.24.30-1.1 ii libgtksourceview2.0-02.10.5-2 ii libpango-1.0-0 1.40.1-1 mousepad recommends no packages. mousepad suggests no packages. -- no debconf information
Bug#822069: mousepad: CPU/disk usage may reflect extensive GLib/GTK+ errors
Package: mousepad Version: 0.4.0-3 Followup-For: Bug #822069 Dear Maintainer, Hi! Thank you for your time and dedication that helps #Debian make computing a possiblity for poverty level individuals! Additionally, my apologies that I've known about this for an extended period. This is the first chance available to pull together a cognitively comprehensible bug report. While cosidering opening a new bug, reportbug offered bugs #797306 and #797307. Those 2 bugs are *not* why I'm filing my report, but that is only because I don't go to that extent in monitoring my system 99% of the time. Ever since stumbling on this bug, there's been no doubt in my mind that it's likely affecting my computer's processing efficiency. My system's version of whatever is going on was found when my rsync backups started hanging up. Rsync turned out to be choking on the hidden file, ~/.xsession-errors, because it was... *1GB* LARGE! :D Mousepad was present in line after line of that output so I threw it into a terminal. Flicker rate was off the charts because the error messages were racing off the terminal screen. Someone over at Xfce marked a similar issue as solved [1] after referencing fonts so I played with those. I decided a scientific approach would be to test some other user variable so I played with theme settings. In that 2 minutes of playing with alternating theme settings, my *latest* ~./xsession-errors file went from 111914 lines of error messages to a tremendous 1148486 lines. TWO MINUTES! :) A sampling of the errors generated is as follows: +++ BEGIN MOUSEPAD ERRORS +++ (mousepad:1034): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed (mousepad:1034): GtkSourceView-CRITICAL **: gtk_source_style_scheme_get_id: assertion 'GTK_IS_SOURCE_STYLE_SCHEME (scheme)' failed (mousepad:1034): GtkSourceView-CRITICAL **: gtk_source_style_scheme_manager_get_scheme: assertion 'scheme_id != NULL' failed +++ END MOUSEPAD ERRORS +++ With respect to root getting a hat tip in one of the related bugs, that's actually where I initially observed the "flicker rate" effect of so many lines of errors flashing by. Because it's basically the same errors repeated, that flicker rate is easy to miss because the repetitious errors keep replacing each other on the screen. My terminal window just happened to be sized differently at that moment the flicker rate became visible. Lastly, I chose to addend to bug #822069 since it's the newest number and the others were merged to it. In conclusion, thank you again *so much*. Mousepad is one of the packages left open here all day every day! Well, except for a brief period of time where it was a conscious *_CHOICE_* based on the assumption that this bug surely had to be direly affecting CPU efficiency somehow, no joke. :) Peace and best wishes from Talking Rock, Georgia! Cindy (Sue) :) [1] https://forum.xfce.org/viewtopic.php?id=9518 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mousepad depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-1 ii libc62.22-7 ii libglib2.0-0 2.48.0-1 ii libgtk2.0-0 2.24.30-1.1 ii libgtksourceview2.0-02.10.5-2 ii libpango-1.0-0 1.40.1-1 mousepad recommends no packages. mousepad suggests no packages. -- no debconf information
Bug#762909: /usr/bin/apt-show-versions: Multiple upgrades available, apt-show-versions shows none
Package: apt-show-versions Version: 0.22.7 Followup-For: Bug #762909 Dear Maintainer, Subject: Re: /usr/bin/apt-show-versions: Multiple upgrades available, apt-show-versions shows none Followup-For: Bug #762909 Package: apt-show-versions Version: 0.22.7 Dear Maintainer, First and as always, THANK YOU for your time and dedication that helps make Debian possible overall! Secret between you and me, apt-show-versions is permanent Top 5 of software packages I LOVE! Secondly, I wasn't sure whether to actually change the subject line so I didn't because my situation is similar. This bug reproduced itself on my system. "apt-get upgrade" shows 21 packages while "apt-show-versions -u" only shows 18 in the works of needing attention for my setup right now. These three are the ones apt-get shows that apt-show-versions does not: libnet-dns-perl php-text-languagedetect php-xml-svg In case something about the following helps distinguish what's causing the glitch, both currently acknowledge these 18 as needing upgraded: chromium cpp cpp-5 firefox-esr g++ g++-5 gcc gcc-5 gcc-5-base libasan2 libblkid1 libgcc-5-dev libmpx0 libpulse-mainloop-glib0 libpulse0 libstdc++-5-dev php-horde-mongo tzdata My apologies that this has been going on for several months. I just hadn't been able to cognitively pull together the correspondence to report it. :) For kicks while writing this up, I just upgraded apt-get's 3 singly then ran apt-show-versions after each. Nothing changed in what apt-show-versions reported. That's all I can think of right now. Thank you again *so much*! Apt-show-versions has been a PHENOMENAL TOOL with respect to having to minutely control upgrades over dialup Internet access. Best wishes from Talking Rock, Georgia! Cindy (Sue) :) * runs with duct tape * -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-show-versions depends on: ii apt 1.2.11 ii libapt-pkg-perl 0.1.29+b5 ii libperl5.22 [libstorable-perl] 5.22.2-1 ii perl5.22.2-1 apt-show-versions recommends no packages. apt-show-versions suggests no packages. -- no debconf information
Bug#816210: libldb1: Upgrade removes xine-ui, kde-runtime + 8 more (Sid Unstable)
Package: libldb1 Version: 2:1.1.24-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, First and as always, thank you to EVERYONE for your time and dedication that makes Debian possible! The bug I've encountered today involves the latest upgrading of package libldb1 via apt-get on Sid Unstable. This is the advisement received when attempting that upgrade: +++ BEGIN APT-GET'S LIBLDB1 UPGRADE ADVISEMENT +++ The following packages will be REMOVED: kde-runtime kio-extras libsmbclient libxine2 libxine2-misc-plugins libxine2-plugins palapeli samba-libs vlc-plugin-samba xine-ui The following packages will be upgraded: libldb1 1 upgraded, 0 newly installed, 10 to remove and 0 not upgraded. Need to get 111 kB of archives. After this operation, 40.3 MB disk space will be freed. +++ END APT-GET'S LIBLDB1 UPGRADE ADVISEMENT +++ Once in a while I get lucky where installing/upgrading all other packages first or in a different order remedies the situation. Unfortunately that did not help today. If you look at this bug report and agree with its assignment, cool. If you think it's something that usually should not make it to bug report status, I'll be happy to receive that feedback as part of the growing process in learning to help you all out. The reason I say that is because I always end up cringing while determining the severity status of these things. I'm not well enough versed in the whole dependency thing to know whether xine-ui, kde-runtime, and the others being removed by libldb1 is an expected behavior that is very naturally remedied regularly in Sid Unstable. I ultimately choose that severity because, for example today, it doesn't appear to be a natural, expected behavior for a media player and game (e.g. palapeli) to be autoremoved during the *seemingly* unrelated update of a package being addressed by itself. That's all I have for now. Thank you again so much for your work! PS As an aside, I just seconds ago installed apt-rdepends with hopes that it proves to be a useful tool for understanding situations like this in the Future. Cindy Sue :) Talking Rock, GA USA -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libldb1 depends on: ii libc6 2.21-9 ii libldap-2.4-2 2.4.42+dfsg-2+b2 ii libtalloc2 2.1.5-1 ii libtdb11.3.8-1 ii libtevent0 0.9.28-1 libldb1 recommends no packages. libldb1 suggests no packages. -- no debconf information
Bug#809658: ifupdown: Upgrade 0.8.5 Removes 48 Unrelated Packages e.g. linux-image, xorg, udev (Sid Unstable)
Package: ifupdown Version: 0.8.4 Severity: critical Justification: breaks the whole system Dear Maintainer, Hi.. First, thank you all for the work you do! Next: I ran my usual "apt-get update" today. Found ifupdown needing upgraded in Sid Unstable along with ~20+ other packages. When the upgrade process began, I received an apt-get advisement that 48 packages were going to be removed. Being familiar with this occurrence at this point, I manually installed packages one by one and determined ifupdown to be the package performing the removals. The following (extensive) output is what I receive when attempting to install ifupdown by itself: +++ The following packages will be REMOVED: blueman bluez colord gvfs gvfs-daemons iio-sensor-proxy initramfs-tools libpam-systemd linux-image-4.1.0-1-amd64 network-manager network-manager-gnome policykit-1 policykit-1-gnome systemd systemd-sysv udev udisks2 upower xfce4-power-manager xfce4-power-manager-plugins xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-vmmouse xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-ati xserver-xorg-video-cirrus xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nouveau xserver-xorg-video-openchrome xserver-xorg-video-qxl xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-savage xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-vesa xserver-xorg-video-vmware The following NEW packages will be installed: sysvinit-core The following packages will be upgraded: ifupdown 1 upgraded, 1 newly installed, 48 to remove and 23 not upgraded. Need to get 204 kB of archives. After this operation, 243 MB disk space will be freed. +++ A quick trip to "apt-show-versions [package-name]" shows all of ifupdown's depends to at least appear current. My latest practice under these circumstances is to set the affecting package to the side and wait for developers' newer release of the same. Thank you again for all your work! Cindy Sue :) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.24 ii iproute2 4.3.0-1 ii libc62.21-6 ii lsb-base 9.20150917 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.3-5 Versions of packages ifupdown suggests: ii ppp 2.4.7-1+1 pn rdnssd -- no debconf information
Bug#808239: perl: Perl, Perl-Base Upgrade Uninstalls 144 Unrelated Packages e.g. Xorg (Sid Unstable)
Package: perl Version: 5.20.2-6 Severity: critical Justification: breaks the whole system Dear Maintainer, Hi.. First, thank you all for the work you do! Next.. I ran my usual "apt-get update" today. Found perl and perl-base needing upgraded in Sid Unstable along with ~20+ other packages. When I began the process to upgrade all those packages together, I received an apt-get advisement that 144 packages were going to be removed. Xorg was just the most important that stuck out, hence this bug's subject line. There are numerous other programs/packages being touched on here in addition to Xorg. A quick manual run down the list of packages needing upgraded showed both perl and perl-base to be the packages attempting the uninstalls. For simplicity's sake, the following (extensive) output is what I receive when attempting to install perl by itself: +++ The following additional packages will be installed: libperl5.22 perl-base perl-modules-5.22 Suggested packages: perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl The following packages will be REMOVED: apt-file apt-show-versions aspell aspell-en claws-mail claws-mail-i18n console-setup console-setup-linux debconf-i18n dictionaries-common enchant gnome-user-guide hunspell-en-us inkscape keyboard-configuration libalgorithm-diff-xs-perl libapt-pkg-perl libb-hooks-endofscope-perl libb-hooks-op-check-perl libbareword-filehandles-perl libcairo-perl libcgi-fast-perl libcgi-pm-perl libclass-accessor-perl libclass-c3-xs-perl libclass-xsaccessor-perl libclone-perl libcommon-sense-perl libcrypt-ssleay-perl libdata-optlist-perl libdata-perl-perl libdata-section-perl libdevel-caller-perl libdevel-lexalias-perl libemail-valid-perl libenchant1c2a libfcgi-perl libfile-fcntllock-perl libgetopt-long-descriptive-perl libglib-perl libgtk2-gladexml-perl libgtk2-perl libgtkspell0 libhtml-form-perl libhtml-format-perl libhtml-parser-perl libhtml-tree-perl libimage-magick-perl libimage-magick-q16-perl libimport-into-perl libindirect-perl libio-pty-perl libio-socket-inet6-perl libio-socket-ssl-perl libipc-run-perl libjson-xs-perl liblexical-sealrequirehints-perl liblist-moreutils-perl liblocale-gettext-perl liblwp-protocol-https-perl libmailtools-perl libmath-random-isaac-xs-perl libmime-tools-perl libmodule-implementation-perl libmodule-runtime-perl libmoo-perl libmoox-handlesvia-perl libmultidimensional-perl libnamespace-autoclean-perl libnamespace-clean-perl libnet-dbus-perl libnet-dns-perl libnet-smtp-ssl-perl libnet-ssleay-perl libossp-uuid-perl libpackage-stash-perl libpackage-stash-xs-perl libpadwalker-perl libpango-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libparse-debianchangelog-perl libperl5.20 libperlio-gzip-perl libpod-readme-perl libsoap-lite-perl libsocket6-perl libsoftware-license-perl libsub-exporter-perl libsub-identify-perl libsub-name-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtext-wrapi18n-perl libtype-tiny-xs-perl libtypes-serialiser-perl libunicode-utf8-perl libvariable-magic-perl libwebkitgtk-3.0-0 libwww-perl libxml-parser-perl libxml-twig-perl libxmlrpc-lite-perl libyelp0 lintian miscfiles moreutils perl-modules qemu-launcher tasksel tasksel-data xorg xscreensaver xscreensaver-data xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-vmmouse xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-ati xserver-xorg-video-cirrus xserver-xorg-video-fbdev xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nouveau xserver-xorg-video-openchrome xserver-xorg-video-qxl xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-savage xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-vesa xserver-xorg-video-vmware yelp The following NEW packages will be installed: libperl5.22 perl-modules-5.22 The following packages will be upgraded: perl perl-base 2 upgraded, 2 newly installed, 144 to remove and 24 not upgraded. Need to get 7583 kB of archives. After this operation, 250 MB disk space will be freed. +++ It sometimes works to install/upgrade other packages first then re-attempt upgrading the problem package. So I tried perl-base alone but received similar results to perl. Am taking an uninformed but experience based guess that the other unrelated packages slated to be installed/upgraded today will most likely not change perl's attempt to uninstall things. Since I'm on dialup and it would take a couple hours to test the unrelated packages, it seemed more important to go ahead and bring this to Developers' attention first and as immediately as possible. In conclusion, simply setting the perl and perl-base upgrades to the side is the course of action I
Bug#805176: libldb1: Newest libldb1 upgrade removes Xine-ui video player
Package: libldb1 Version: 2:1.1.21-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, Hi.. I just completed running "apt-get update" followed by "apt-show-versions -u" to find that 3 packages needed upgraded: hostapd, libldb1, and wpasupplicant. While upgrading those, I received the error message that xine-ui was going to be removed by that upgrade. Thankfully the upgrade list was short this morning so a quick one by one test showed libldb1 is the package trying to remove THE video and other media file player I hand chose for my debootstrap'd Debian here. The expected outcome is, of course, to have all handchosen packages remain in place after all current upgrades have been installed. While writing up this bug report, I simultaneously installed the other 2 packages as a test. SOMETIMES that corrects this very type of bug. It's been my accidental discovery that occasionally the order of one package installation before all others plays a part in stopping a second package from removing a third *seemingly* unrelated package. That path unfortunately didn't help this time so I have no suggested temporary workaround for anyone likewise affected. If I stumble on anything, I'll share here. The related "apt-get install" advisement that I'm receiving is: +++ The following packages will be REMOVED: libsmbclient libxine2 libxine2-misc-plugins libxine2-plugins samba-libs xine-ui The following packages will be upgraded: libldb1 1 upgraded, 0 newly installed, 6 to remove and 2 not upgraded. Need to get 111 kB of archives. After this operation, 24.1 MB disk space will be freed. +++ For right now, this is all I have. Thank you so much for the work you do! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libldb1 depends on: ii libc6 2.19-22 ii libldap-2.4-2 2.4.42+dfsg-2 ii libtalloc2 2.1.5-1 ii libtdb11.3.8-1 ii libtevent0 0.9.26-1 libldb1 recommends no packages. libldb1 suggests no packages. -- no debconf information
Bug#800602: Lightdm: orca speaks characters while typing the password.
On 10/19/15, Ksamak <ksa...@hypra.fr> wrote: > > Actually, this bug seems to mostly appear when the following option is set: > [SeatDefaults] > greeter-hide-users=false > This is mainly used to have the "main" user directly written in the > first field, so as not to retype it every boot. > > So when you have this option activated, the focus is directly put on the > password field, and then the bug appears. > if the user circles through the fields once, with tab, then back on the > password field, the bug disappears. > > I've seen it appear as well when two users are set-up on the system, but > i'm not sure about the exactness of my reproduce steps, so i'll try > again if people find the bug Could Not Reproducable > > I can make available a VM with the bug appearing at boot, for tests > (3.6Gb) > lightdm version 1.10.3-3, jessie current. I THINK this is only my second bug I've tried to assist with so I didn't want to be the participant who keeps responding to herself. Just as soon as I offered up my previous observation re the possibility of toggling password masking on and off, I found the following pre-existing bug: Bug #736964; Dated January 28, 2014 Bug Title: [lightdm] Password is shown in cleart text while typing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736964 The extremely short synopsis is that, exactly as Ksamak shared here in this current bug report, "greeter-hide-users=false" was determined to be at least one culprit. The ultimate outcome at the end of that bug report is it appears to have possibly been determined to be a Launchpad responsibility. Because lightdm is so small, I was able to download both the source and the .deb archive file just to nose around to see if I could help you all further. I don't know the ultimate default outcome during installation of either of those versus the other BUT. * within the .deb archive file (the i386 version), /etc/lightdm/lightdm.conf references "greeter-hide-users=false". It's initially commented out, but I *presume* "false" is its default value if/when activated. Wondering out loud: Is it perhaps an option offered to users during the installation process? If it is, maybe it needs to be better described in some way at that moment so users fully understand the consequence of that particular user CHOICE. * the .xz compilable source file contains a file called 01_debian.conf which references "greeter-hide-users=true". That's the only place I found it in the .xz file after briefly extracting and then grepping for that variable. Its value is noticeably the absolute opposite of the same variable found in the .deb file. As you all have already determined, the value "true" definitely sounds the more secure screenreader related CHOICE. Am just sharing the above, particularly the previously reported bug, since the bug appears very similar so maybe there is something that was already addressed by Developers that could help short track Debian's fix. As has been discussed already, this is definitely a high security risk for Debian Users with visual impairments. I wish I understood Debian's inside coding more so I could be in there helping you all nail it down. Good luck! Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#800602: Lightdm: orca speaks characters while typing the password.
On 10/18/15, Samuel Thibault <sthiba...@debian.org> wrote: > > Raphaël POITEVIN, le Thu 01 Oct 2015 17:12:20 +0200, a écrit : >> I type my password directly, with the default selected user. Orca speaks >> characters. > > I'm not getting that behavior. I tried installing both stable and > testing, in both cases I'm getting "asterisk" in the password field. In > the stable case, I tried to install 3.16.2-1, with the same result. Hi, is it possible that the password field in question has been triggered to visibly display the word instead of the asterisks? Forgive me for not having a reproducible example handy, but I've seen it couple times in the last few weeks. Because I can't remember an exact example, it's possible it was even for something online. Decided to offer it up anyway since I've seen it in action AND because it's interesting Samuel's hearing asterisks while Raphael's hearing the actual password.. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
Bug#800477: libxine2 Sid upgrade fail: 2 unmet dependencies
Hi, again. Wasn't sure how to do this but it seemed potentially appropriate to announce an already found temporary workaround as a top post. Installing "libxine2-misc-plugins" BY ITSELF subsequently also successfully installed libxine2 AND the remaining dependencies with no further aborts or uninstall attempts by "apt-get". Prior to doing so, I tested "libxine2", and it still was NOT installing at that moment. Xine was tested for my usual limited uses, and all is fine. "dpkg -s" shows the version is now current, too. Even thinking of doing this "backdoor" approach was just something I stumbled on once in desperation. Sometimes it works, sometimes it doesn't. Just didn't occur to me to attempt the rest of the dependencies when my first backdoor'ed dependency install attempt failed. Again, this is my first bug report so likewise in please do let me know if I should have presented this response in a more appropriate bug report friendly way, including possibly NOT including as much of the original report as I did here.. Thank you again. Best wishes! Cindy Sue Causey Talking Rock, Georgia, USA On 9/29/15, Cindy Sue Causey <butterflyby...@gmail.com> wrote: > Package: libxine2 > Version: 1.2.6-1+b4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Dear Maintainer, > > This is my very first bug report so please forgive any incidental missteps > in this report. I chose Severity #2 Grave because this bug fits the "renders > package uninstallable" criteria under that severity level. My thought > process is it inhibits the installation of packages that could potentially > contain your most recent security patches. > > So what happened was: Today I ran "apt-get update" followed by > "apt-show-versions -u" multiple times as is my daily routine. Results were > the same each time I manually tried to upgrade libxine2 (via "apt-get > install"). Its package install/upgrade was unsuccessful and generated the > following informative (snipped for brevity): > > libxine2 : Depends: libxine2-plugins (= 1.2.6-1); libxine2-misc-plugins (= > 1.2.6-1+b5) > E: Unable to correct problems, you have held broken packages. > > On a whim, I tried a backdoor approach via an install attempt of (randomly > chosen) libxine2-x. I immediately aborted that approach upon seeing the > following advisement: > > The following packages will be REMOVED: > libxine2 libxine2-misc-plugins libxine2-plugins xine-ui > > My approach for now will be to leave the previous libxine2 related packages > as were in anticipation that your Development Team will correct the > situation as soon as Humanly possible. > > Thank you so much for the work you do. Xine is one of my relatively few > installed Debian packages hand chosen for being Xfce4 AND user friendly. > > PS My presumption is you will not need further input as this particular type > of bug appears to be a regular, accepted occurrence in Unstable. If you do > require further feeback, please note that specifically so that I cognitively > grasp that my part of this process is not complete yet. :) > > Cindy Sue Causey > Talking Rock, Georgia, USA > > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libxine2 depends on: > ii libxine2-bin 1.2.6-1+b4 > ii libxine2-misc-plugins 1.2.6-1+b4 > ii libxine2-plugins 1.2.6-1 > > Versions of packages libxine2 recommends: > ii libxine2-doc [libxine-doc] 1.2.6-1 > ii libxine2-ffmpeg 1.2.6-1+b4 > > Versions of packages libxine2 suggests: > pn gxine > ii xine-ui 0.99.9-1.2 > > -- no debconf information
Bug#800477: libxine2 Sid upgrade fail: 2 unmet dependencies
Package: libxine2 Version: 1.2.6-1+b4 Severity: grave Justification: renders package unusable Dear Maintainer, Dear Maintainer, This is my very first bug report so please forgive any incidental missteps in this report. I chose Severity #2 Grave because this bug fits the "renders package uninstallable" criteria under that severity level. My thought process is it inhibits the installation of packages that could potentially contain your most recent security patches. So what happened was: Today I ran "apt-get update" followed by "apt-show-versions -u" multiple times as is my daily routine. Results were the same each time I manually tried to upgrade libxine2 (via "apt-get install"). Its package install/upgrade was unsuccessful and generated the following informative (snipped for brevity): libxine2 : Depends: libxine2-plugins (= 1.2.6-1); libxine2-misc-plugins (= 1.2.6-1+b5) E: Unable to correct problems, you have held broken packages. On a whim, I tried a backdoor approach via an install attempt of (randomly chosen) libxine2-x. I immediately aborted that approach upon seeing the following advisement: The following packages will be REMOVED: libxine2 libxine2-misc-plugins libxine2-plugins xine-ui My approach for now will be to leave the previous libxine2 related packages as were in anticipation that your Development Team will correct the situation as soon as Humanly possible. Thank you so much for the work you do. Xine is one of my relatively few installed Debian packages hand chosen for being Xfce4 AND user friendly. PS My presumption is you will not need further input as this particular type of bug appears to be a regular, accepted occurrence in Unstable. If you do require further feeback, please note that specifically so that I cognitively grasp that my part of this process is not complete yet. :) Cindy Sue Causey Talking Rock, Georgia, USA -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libxine2 depends on: ii libxine2-bin 1.2.6-1+b4 ii libxine2-misc-plugins 1.2.6-1+b4 ii libxine2-plugins 1.2.6-1 Versions of packages libxine2 recommends: ii libxine2-doc [libxine-doc] 1.2.6-1 ii libxine2-ffmpeg 1.2.6-1+b4 Versions of packages libxine2 suggests: pn gxine ii xine-ui 0.99.9-1.2 -- no debconf information
