Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
First, by all means, if you want to develop, package and maintain this app in keeping with the quality standards a Linux distro like Debian demands, go to it. Having said that, it sounds like one of the goofiest things I have heard of recently, and I can not see ever having a use for it. But that does not remotely mean that it should be disallowed. I have done my share of coding little functions which I adore, but which most people have not heard of, and would have little interest in. It doesn't ruin my day. I'll share, but I am Customer Number One. With gender-guesser, if I ever saw it on a list of available modules, I'd say "Huh, sounds like trouble waiting to happen. No, thanks." and that would be all. It may be well-intentioned, but most people aren't triggered if a computer gets their gender wrong, and those that are triggered by that sort of thing tend to go full Karen if the guess is wrong. Therefore you may be setting yourself up for primarily intense and negative feedback. On 7/15/22 19:01, Marvin Renich wrote: * Jeremy Bicha [220714 10:06]: On Thu, Jul 14, 2022 at 2:41 PM Roberto C. Sánchez wrote: On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote: edw...@4angle.com wrote: Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: gender-guesser Version : 0.4.0 Upstream Author : Israel Saeta Pérez * URL : https://github.com/lead-ratings/gender-guesser * License : GPL-3 & GFDL-1.2+ Programming Lang: Python Description : Guess the gender from first name Oh, not *another* package that tries to guess things from names. Do you have a real use for this package? Why in the world is that even a relevant question? There are plenty of packages in the archive which are useful to essentially nobody apart from the maintainer and there are even packages which are maintained without being useful to the maintainer at all (but rather useful to others). There are a *lot* of issues in this area, and mis-gendering people is not something to risk lightly... "There are a *lot* of issues in this area" seems rather nebulous. In which area? Given the fact that we have clear and rather unambiguous guidelines for what constitutes software which is appropriate for inclusion in the archive, and given that on its face this software does not seem to be in conflict with any of those guidelines, what then is the problem? BTW, I'm not interested in any sort of "well I don't like ..." or "such and such could offend so and so ..." sort of arguments. Debian has a Diversity Statement [1] which says that Debian welcomes people regardless of how they identify themselves. Trans people and non-binary people face a lot of discrimination, harrassment and bullying around the world. That bad treatment of these people is against Debian's core values. Therefore, the Debian Project wouldn't want to distribute software that appears to facilitate that kind of harassment, regardless of the software license it is released under. We might not want to distribute such software even if it also has non-harmful uses. We don't have to distribute *everything* ourselves. People within the Debian community have a right to expect that others in the community will not bully, harass, or denigrate them. They do _not_ have any right to expect that others will not offend them by discussing or making contributions that espouse values that are different and incompatible with their own. Such an expectation assumes that one set of values is correct and the other is wrong. In order for such an expectation to be met, only one of the two sets of values could exist within Debian. Saying that gender-guesser should not be packaged within Debian (using the excuse given early in this thread) is excluding a contribution based on the values to which that package adheres and possibly the contributor and the users who would like to use it. This is contrary to being inclusive. Being offended by someone else's civil expression of their values (including the packaging of a particular piece of software) is not the same as being bullied or denigrated. Please stop trying to use the excuse "it might offend someone" to block participation or inclusion of software. Instead, be inclusive and acknowledge that others' values may be different from and incompatible with yours, and accept that Debian is a collection of software from diverse sources and some of it may not adhere to your values. This is the difference between true inclusiveness and the false "political correctness" that seems to be permeating our society today. When we can all say, "I disagree with your values, but I accept you as a Debian contributor," then we will be truly inclusive. ...Marvin
Re: ISS is running GNU Linux Debian :)
It IS noice. I know change is inevitable, yada, yada... I ran Centos 5 and 6 for around 10 years and thought I had found the One. I could make those suckers tap dance around Windows. Centos 7 went totally off the rails, and here I be. Don't forget... On 2/10/22 3:39 PM, dude wrote: > > International Space Station adopts Debian Linux, drops Windows & Red > Hat into airlock X-D > > https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock > > > Boldly Going, Running Linux in Space" - Sam Bishop (LCA 2022 Online) > > as seen on https://ytpak.net/watch?v=G1fOZr9v2lY > > #NOICE! ✌️⭐ > > GO DEBIAN GO! (to Mars and beyond!) >
Evolution
Just a quick question as to whether Evolution Mail is still supported/updated? Wikipedia and Gnome support pages don't have much information on it.
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
This is interesting. First, I must ask... Are either Ralink or Atheros more quickly adopted into Linux support before Realtek? Are they more stable, etc.? (In my original post, I noted that I pulled a Realtek based 5ghz dongle from an extreme end user system, in no small part due to stability/reliability)? Second, I must note that perhaps you *were* lucky or whatever, as I have never found anything other than a Realtek chipset on offer. Even if Atheros or Ralink are more stable, I don't know if I could actually *find* one. I am well aware that the Chinese company's dongle made in People's Dongle Factory Thirteen will have folded before the container ship hits the States, but the Realtek chipset is the key...it is finally why I know that can work with it. On 4/4/21 5:27 AM, Andrej Shadura wrote: > > On Sun, 4 Apr 2021, at 11:25, Andrej Shadura wrote: >> On Thu, 1 Apr 2021, at 21:22, Devops PK Carlisle LLC wrote: >>> Something I did not mention before, to answer your question the chip >>> reads as rtl8821cu (so yes, a Realtek). >>> >>> In fairness I do not recall ever having run across a wifi dongle that >>> did not have a Realtek chip (although they may be out there). It was >>> because I could at least confirm a Realtek chip in an otherwise cheap >>> Chinese dongle, that I was willing to even try it. >> >> I may be lucky or picky or whatever, but all except just one of my >> external USB dongles have Atheros chips. > > Oh, and another one has a Ralink chip. >
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
Something I did not mention before, to answer your question the chip reads as rtl8821cu (so yes, a Realtek). In fairness I do not recall ever having run across a wifi dongle that did not have a Realtek chip (although they may be out there). It was because I could at least confirm a Realtek chip in an otherwise cheap Chinese dongle, that I was willing to even try it. On 4/1/21 2:52 AM, Andrey Rahmatullin wrote: > On Wed, Mar 31, 2021 at 10:38:11PM -0400, Michael Stone wrote: >> On Tue, Mar 30, 2021 at 10:20:03PM +0500, Andrey Rahmatullin wrote: >>> Not sure what hardware you are talking about but the majority of WiFI >>> hardware is supported by the mainline kernels, at least after you load >>> their firmware. >> >> I assume you haven't tried very much wifi hardware. Realistically, the state >> of wifi support is still terrible. The best thing to do is try to buy >> something known to be supported, but that's relatively difficult for most >> people because the name on the box generally has nothing to do with the >> chips inside the box. > Can you please list some unsupported chips in addition to these specific > Realtek ones? >
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
I will note something similar, except that I went into it with my eyes open... Originally (10 years ago), 2.4ghz wifi was not natively supported. Okay, said we geeks, can it be compiled and inserted manually? Yes, it could. I wrote a script to compile and insert said driver, and thereafter, every time there was a kernel update or patch, that's what I did. And it worked fine for the couple of years it took for 2.4ghz to be natively supported in Linux. Fast forward to 2 months ago. Looking at 5ghz wifi, I *knew* what I was volunteering for when I saw a 5ghz wifi dongle on Amazon (one of the questions was: Is it supported for Linux? *I* snickered, as I has a very good idea what the implications were). I bought one, and, back to old school, I can and do run it, manually compiling and inserting the driver as needed. It's a very familiar process. Here's a real world application: in fact I bought *two* 5ghz dongles, one for myself, one for an *extreme* end user whose system I administer. On my system, as needed, compile and reinsert driver. On her system, I pulled the 5ghz, went back to the 2.4ghz dongle, trusting that she won't see the difference. No big deal, not a complaint, I am PERFECTLY comfortable with compiling and inserting a driver (compare and contrast that to Windows, where you are SOL if there is not a driver available, I *do* get it)...more a point in the right direction. This is where we were 10 years ago with 2.4ghz. On 3/29/21 8:59 PM, Timothy M Butterworth wrote: > All, > > Currently in Bullseye the Realtek 8822CE WiFi adapter is not being > recognized. There is a patched driver available at: git clone > https://github.com/lwfinger/rtw88.git is it too late to get this > driver into Bullseye. I ask because I have a laptop with a 8822CE > adapter that is not functional. > > More info on getting Realtek adapters working: > https://easylinuxtipsproject.blogspot.com/p/realtek.html#ID7 > > Tim >
IBus emoji glitch
This is seen with Debian GNU/Linux 10 (buster) IBus 1.5.19 When you select the emoji function, it comes up as expected, can select an emoji as expected from the graphical window...but... When I mouse over a given emoji (call it Smiley 1) Smiley 1 may have three lines of technical or category data which appears at the top of the window, above the graphical emoji set. Smiley 2, right next to Smiley 1 may have four lines of technical or category data, Smiley 3 may have three lines of technical or category data, etc. Because these lines of technical or category data are *above* the emojis, *and* the entire window literally shrinks or expands, that is, resizes, to accommodate the number of lines of technical or category data, the entire emoji window literally shifts up or down a line depending on how many lines of technical or category data that emoji has. So, as I navigate with a mouse from Smiley 1 to Smiley 2 to Smiley 3, the window is literally resizing on the fly (and the entire block of emojis shifts up or down), making it difficult if not impossible to use the mouse to select some emojis. In the best world either the technical and category data would be underneath the graphical emoji block OR the number of lines of technical or category data would be static so the graphical emoji block did not resize and shift up or down as the user rolls from one emoji to the next.
Re: Disabling automatic upgrades on Sid by default?
I would like to be able to selectively exclude-with-a-warning some packages from automatic update as I choose, and to have the update process remember those choices from one update instance to the next: Chrome browser: Version a.b.c will be installed Firefox: Version d.e.f will be installed Kernel g.h.i is available (automatic update disabled by user) Libre Office j.k.l will be installed ... If I know that, for instance, a kernel update will break a wifi dongle driver or NVIDIA driver, either I must not use automatic updates at all and I must remember which packages I don't want to update and manually exclude those packages every time OR I must have enough time to repair what will break (and may update less often as a result). Now I understand the potential for dependency issues if selective disabling of updates is possible, but that's okay, that's Linux. Provide a warning about dependencies if that's detected and leave it up to the user to decide. On 12/27/20 1:01 AM, M. Zhou wrote: > Hi folks, > > I don't quite understand the meaning of automatic upgrades on a rolling > system such as Debian/Sid. According to my own experience, such > automatic upgrades could be dangerous. > > Recently package ppp is pending for upgrade but it does not co-exist > with my currently installed network-manager. Today when I was shutting > down my machine, Gnome automatically checked the "install updates ..." > box for me before I realized its existence. As a result, the system > reboots and installed ppp by force, removing network-manager and break > my system for daily use as I need network-manager for wifi-access. > > I've been a daily Sid user for at least 4 years. Automatic upgrades are > to blame for nearly all my system troubles. And I feel very > disappointed every time linux behaves like M$ windows. > > So, do we have a consensus on whether automatic upgrades should be > enabled by default? >
Do I need a sponsor to submit a new package?
I have written a small utility in Linux to automatically update wallpaper on the desktop from either locally saved images or images retrieved online. It is written in Python, is ridiculously simple code for what it does, and has never failed to run correctly in any version of Linux I have tried it with. I submitted it to the wishlist, and believe that I have followed the rules in that process. If I did things correctly, everything needed is referenced here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976174 Is there a next step that I need to take? Thanks!
Re: Release status of i386 for Bullseye and long term support for 3 years?
I understand your point about 32 bit being updated forever, and perhaps it does not need to be. Perhaps the happy medium would be to freeze it at some point, but leave it available as-is so that legacy software with 32 bit dependencies can still be installed and run. In other words, no longer developing for 32 bit does not mean that it cannot be found. Perhaps a different repository, with disclaimer(?) so that users can enable it if desired? On 12/15/20 8:47 AM, Michael Stone wrote: > On Sun, Dec 13, 2020 at 11:40:29AM -0500, Devops PK Carlisle LLC wrote: >> Being philosophically opposed to throwing a good machine into a >> landfill, I tend to hang on to equipment for a long time. My >> play/experimentation and last-ditch backup box is a 10 year old laptop. > > I hear that, but at least around here it's literally possible to grab > machines that are less than 10 years old that are on their way to the > landfill. So scratch your itch by saving a machine less than 10 years > old, then throw the really old one away instead. I'm unconvinced that > running a stable of unneeded old machines is either great from a waste > standpoint or something that should dictate the direction of the > project. Debian isn't devoted specifically to supporting functionally > obsolete hardware indefinitely, and when obsolete hardware makes it hard > to move forward we need to just drop it. There are other projects which > do strive to support old hardware indefinitely, and I highly recommend > looking at one of those if hardware you want to use is no longer > supported by debian. I personally run netbsd on some of my nostalgia > hardware, but there are other options that may work better for you > depending on what you're trying to do. >
Re: Release status of i386 for Bullseye and long term support for 3 years?
Being philosophically opposed to throwing a good machine into a landfill, I tend to hang on to equipment for a long time. My play/experimentation and last-ditch backup box is a 10 year old laptop. During COVID I spent a little time updating and upgrading it and came up with this: https://go.carlisle.pk/5boot Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 40 bits physical, 48 bits virtual CPU(s): 1 On-line CPU(s) list: 0 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 NUMA node(s):1 Vendor ID: AuthenticAMD CPU family: 15 Model: 124 Model name: AMD Athlon(tm) Processor TF-36 Stepping:2 CPU MHz: 1600.000 CPU max MHz: 2000. CPU min MHz: 800. BogoMIPS:3192.06 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache:256K NUMA node0 CPU(s): 0 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid pni cx16 lahf_lm svm extapic cr8_legacy 3dnowprefetch vmmcall lbrv The hardware is 64 bit, but as I still have some truecrypt volumes in use, and the truecrypt installer is 32 bit, I run elements of each (this is on both Debian and an Ubuntu tower). I can run everything from G-Suite to Netflix -- maybe what will eventually kill it is requirements of cloud services. I would also argue that the ability to support equipment even once Microsoft decides to no longer support it has long been one of the arguments given out in favor of Linux over Windows. On 12/13/20 2:14 AM, Calum McConnell wrote: > Hi all, > As someone who runs amd64/i386 multiarch, this statement from Adrian: > > >> i386 hardware is so numerous and widely spread, that every tiny fraction >> of i386 users might be more users than half of our release architectures >> combined. It is not even clear whether this is just an exaggeration or >> might be literally true: > > intrested me. I wondered just how many there were. Popcon lists 17281 > people with i386 installations, but I bet that includes those who (like > me) installed multiarch. So I grep'ed through the popcon output a bit, > looking for kernel packages. I figure that, if you have an i386 kernel > pacakge, you don't belong in the first group of people. > > Obviously you all can easily replicate this, and this only applies to > users with popularity-contest installed, but here are my results: > > For a baseline, there are 181,863 amd64 users who are regularally sending > popcon reports. Of those, 171,916 have the linux-image-amd64 package > installed. I assume the remaining 5.4 percent are selecting what kernel > package they are running manually, or perhaps are in a VM. > > The 13th most popular linux-image package is linux-image-686-pae, at > 12,736 installs. It places ahead of every single 5.x kernel, indicating > that there are more people running i386 (with some extensions) than there > are running Testing or Unstable. > > Continuing down the list, the standard linux-image-686 package (no PAE) > has 877 popcon installs. None of the other release archetecures have > appeared yet: which isn't supprising, since every other popcon archetecure > has a combined total of 1636 installs, the largest being armhf at 636 > installs. I assume these people are the ones who would lose support: > while some of them may have PAE capable computers, I don't think it's a > significant fraction. > > Clearly, I have already proved Adrian's point: I can say, with certainty, > that there are an order of magnitude more people with i386 kernels (and > thus presumably i386 hardware) than there are for every other non-amd64 > release archetecture combined. Further, there are more people with old > i386 hardware than there are for any other arch. My point is that we > would lose less people if we dropped all ARM support than if we dropped > the oldest supported i386 kernel[1]. > > But lets keep going! See, we haven't seen any arm kernal images yet, so > who knows if they even exist? Remember, the ARM archectures are the > biggest ones after i386. > > Next up, we hit linux-image-586, with 403 installs. That means there are > 403 people who were unable to upgrade to stretch, but are still running > Debian and popcon. That's presumably the lower limit for the number > Adrian referenced as people who were upset with the increase in baseline, > since again, all of those 403 people have used their 586 machine in the > past month. > > Continuing down, we see linux-image-486, 310 installs. That's still more > installations than arm64's total popcon. It's also been unsupported since > 2014, but hey. > > Then we hit linux-image-marvell, which (as I understand it) is one of the > arm versions.
Bug#976174: ITP:papershaper--automagic wallpaper swapper
Package: wnpp Severity: wishlist Owner: Devops PK Carlisle LLC X-Debbugs-Cc: debian-devel@lists.debian.org, dev...@pkcarlisle.com * Package name: papershaper * URL : https://github.com/pkcarlislellc/git-papershaper * License : LGPL-3+ Programming Lang: Python Description : automagic wallpaper swapper Papershaper automatically changes wallpaper from either locally stored images,from webcams, or both. User chooses how often Papershaper updates wallpaper. Originally written in Python 2, now updated to default to Python 3 (Python 2 code is still included for those who want it). Available for download at https://github.com/pkcarlislellc/git-papershaper Available as a tar.gz from https://sourceforge.net/projects/papershaper/ Fully documented at both of these sources.
ITP:papershaper--automagic wallpaper swapper
Subject: papershaper: short description submitting papershaper for Linux Package: papershaper Severity: wishlist Papershaper automatically changes wallpaper from either locally stored images,from webcams, or both. User chooses how often Papershaper updates wallpaper. Originally written in Python 2, now updated to default to Python 3 (Python 2 code is still included for those who want it). Available for download at https://github.com/pkcarlislellc/git-papershaper Available as a tar.gz from https://sourceforge.net/projects/papershaper/ Fully documented at both of these sources.
