GRAUNDMAS Shows Bnig Njatural Byoobs Show Hsairy Pzussy
Good afternoon. OLLDERMOM In Sxtockings Pzosing & Rhiding Dqick Which side of the bed did you get out of this morning, then? : http://offer.flew-one.com/ Sjexy OLDERXMOM With Bfig Bvoobs Shows Acss & Piosing A single idea, if it is right, saves us the labor of an infinity of experiences.Perfection of means and confusion of goals seem -- in my opinion -- to characterize our age. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gpm and time after hamm upgrade
After upgrading to hamm, I have experienced the two following problems. First, gpm no longer seems to work with my mouse. I have a PS/2 M$ Intellimouse, which used to work fine as type ps2. I tried that setup, under which it only moves the cursor erratically and seems to randomly select text. I tried setting the mouse to type ms3, but that produced nothing at all. I have tried setting the mouse as /dev/psaux and /dev/mouse, and have tried closing x windows completely before starting gpm, but nothing seems to help. I am using gpm 1.13-4. The other problem is that, whenever I reboot the machine, it sets the clock back about four hours, but it keeps the timezone as EDT. My timezone is set as America/Detroit.I am using timezones 2.0.7pre3-1. Thanks, Corey Miller --- Corey Miller "This looks like a job for . legal tender!" MSTie #71940 -The Tick [EMAIL PROTECTED] http://www.egr.msu.edu/~mille542/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#649418: ITP: cdm -- login manager for the console
Package: wnpp Severity: wishlist Owner: Corey Richardson * Package name: cdm Version : 0.5.3 Upstream Author : Daniel Griffiths * URL : https://github.com/ghost1227/cdm * License : GPL3 Programming Lang: Bash Description : login manager for the console The Console Display Manager is a lightweight though full-featured login manager supporting multiple X sessions, themes, and more. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2020195602.16650.88305.reportbug@localhost
Re: Upcoming Qt switch to OpenGL ES on arm64
Try glxgears and es2gears on few different platforms. On a Pi 3b glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64 it's in the hundreds of FPS but that's Mali. Look at omxplayer, full screen HD video while the CPU idles (on a Pi). The GPU is more capable than the CPU. You can do software-emulated OpenGL on anything, the question is how efficient it is. On 11/26/18, bret curtis wrote: > Hello Ian, > > On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote: >> >> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote: >> > The hardware that supports GLES also supports OpenGL because GLES is >> > a subset of OpenGL. >> >> I'm confused by this inference. If GLES is a subset of OpenGL then >> surely hardware which claims to implement GLES is at liberty to only >> implement that subset and would therefore not necessarily support >> OpenGL. >> >> Ian. >> > > I believe this is a purely a driver/firmware distinction. So whoever > implements this is at liberty to do whatever they want so long as the > hardware supports it. > > Meaning that if something advertises GLESv2 support then it has, at > least, OpenGL 2.0 support in hardware because without that, they > couldn't have supported GLESv1. > > GLES1.1 is fixed-function pipeline that is compatible with OpenGL 2.0, > you're not going to create hardware to support GLES1.1 that doesn't > also support at least OpenGL 2.0 > > GLESv2 is another beast, it dropped fixed-function pipeline because > that was the spec, but it is still a software implementation and > doesn't mean that it no longer exists in hardware. > > Take for example the Nvidia Tegra: > https://opengles.gpuinfo.org/displayreport.php?id=690 <-- SHIELD > Android TV which happens to be a Tegra SoC supports OpenGL ES 3.2 > https://opengl.gpuinfo.org/displayreport.php?id=2377 <-- Tegra as > integrated with CPU (nvgpu), supports OpenGL 4.6.0 > > Similar (if not the same?) hardware, running aarch64, the only real > difference is the driver. > > That being said, I would love to hear from someone who actually makes > these things to comment. It is entirely possible that there is a chip > out there that supports GLES 3.2 and only that in hardware. I would be > amazed but I'm reluctant to ever use the words never and ever. So far, > the hardware that supports that are[1]: > > Adreno 420 and newer > AMD GCN-architecture > Intel HD Graphics Skylake and higher > Mali-T760 and newer > Nvidia GeForce 400 series (Fermi) > > As I said, I would be amazed if these GPUs didn't support some minimal > version OpenGL in hardware. As I said elsewhere, most free and > open-source drivers (mesa) support both some version of GLES along > with some version of GL. [2] > > Cheers, > Bret > > > [1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2 > [2] https://mesamatrix.net/ > > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Why couldn't you choose QT for Desktop or QT for ES OpenGL when you compile your program? Supply both libraries? ES gives an enormous performance boost to little machines that need it, desktop OpenGL is more pretty pictures. On 11/26/18, Lisandro Damián Nicanor Pérez Meyer wrote: > El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió: >> Hello Lisandro, >> >> TLDR: thank you for starting this discussion, it was required as it's not >> an easy decision to take as there is no realistic perfect solution, > > Our (team-wide) pleasure. This is something we have been digging since > 2015. > >> but I >> believe you took the wrong decision. Please consider deferring the >> decision to the technical committe by seeking his advice (point 6.1.3 >> of the constitution >> https://www.debian.org/devel/constitution.en.html#item-6). > > Will "kind of" do. Read below. > > >> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote: >> > It seems now clear that the general consensus seems to expect: >> > = Qt available for both Desktop and ES OpenGL flavours >> > = If no change is possible, keep arm64 with Desktop OpenGL support >> >> I'm not pleased with how this discussion was handled. First of all, >> you did not leave enough time for all stakeholders to participate in >> the discussion (started on November 22th, closed November 25th, 3 days, >> that's not a reasonable timeframe in particular when 2 of the 3 days >> were in the week-end). > > My most sincere apologies if our timeframe do not fit yours. > > Now, wrt the decision: clearly the situation is very complex, involving many > > different kinds of arm64 devices, drivers, libraries et all. People involved > > have different opinions. We so far have been the proxy between them, be it > on > bugs, IRC or whatever other channels our users have to contact us. We prefer > > not to be this proxy anymore (again, read below). > > Besides we (Qt's team) have just learned that the Desktop/ES support is not > > tied to the hardware but to the driver. That's a particularly interesting > point. > > So: > > To quote my original mail, the "Qt available for both Desktop and ES OpenGL > > flavours" point remains unchanged: if someone wants to make it happen [s]he > > must join the team and support it from the inside. Remember there are little > > chances for this to happen in time for Buster. > > For the second point, "If no change is possible, keep arm64 with Desktop > OpenGL support", we have this position: we will keep the status quo, > deferring > users who want GLES support to Ubuntu. > > *But* we are open to change this for any arch (read it: support either one > or > the other technology) as long as the decision is taken by the technical > committee. As I wrote before, we will keep the status quo, so if anyone is > interested in any change feel free to contact the TC. > > Regards, Lisandro. > > -- > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
broadcast error messages, unofficial Debian 12
This is in an unofficial debian release at https://raspi.debian.net/tested-images/, the one for 8 GB Pis. I've never seen anything like it. I can have 2 or more Zutty terminal windows running to work on a program. When I get a compiling error in one terminal it gets broadcast to both windows. This particular error is not anything in my code, I don't recognize any of it, but it shows up because I had a warning in my stuff: W [main.cc:1161] (Unimplemented) unhandled OSC: '8;; https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable ' W [main.cc:1161] (Unimplemented) unhandled OSC: '8;;' I had a set but not used warning. Yet if I page up and page down where the message is it goes away like it's being written to some video buffer. Alan
Re: broadcast error messages, unofficial Debian 12
Thank you, I'd never heard of Zutty before this Debian turned up using it as a default terminal. Normally I use rxvt, on trying harder rxvt and xterm both installed and don't seem to have the problem. At first I thought I was running under Wayland so I was maybe stuck with Zutty. But there's no Wayland either, at least by default. Anyway this Debian 12 doesn't seem too bad, you just need to turn off (unblock all) rfkill everytime you boot it. On Wed, Dec 13, 2023 at 7:08 PM Andy Smith wrote: > Hi Alan, > > debian-devel is for discussion of the development of debian. Your > query appears to be user support, which takes place on debian-user. > I've set Reply-To: debian-user. > > On Wed, Dec 13, 2023 at 02:52:11PM -0500, Alan Corey wrote: > > I can have 2 or more Zutty terminal windows running to work on a > > program. When I get a compiling error in one terminal it gets > > broadcast to both windows. > > > > This particular error is not anything in my code, I don't recognize any > of > > it, but it shows up because I had a warning in my stuff: > > > > W [main.cc:1161] (Unimplemented) unhandled OSC: '8;; > > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable > > ' > > W [main.cc:1161] (Unimplemented) unhandled OSC: '8;;' > > I'm not familiar with Zutty but this message appears to come from > your terminal, Zutty, which also explains why it appears in all of > your terminal windows. > > An example of suxh a Zutty diagnostic is here: > > https://github.com/tomscii/zutty/issues/43 > > though it is not your specific one. > > So, you probably want to seek support from Zutty, e.g. at their > github issues. > > Thanks, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > -- - Education is contagious.
Re: Ability to further support 32bit architectures
Are you forgetting that 64 bit is slower? In the arm world where it's easily switchable 64 bit is pokey when you don't need it. On Fri, Jan 12, 2024, 12:54 PM wrote: > > > Sent from my mobile device. > > -- > *From:* YunQiang Su > *Sent:* Friday, January 12, 2024 10:11 > *To:* r...@neoquasar.org > *Cc:* noloa...@gmail.com; debian-ker...@lists.debian.org; > debian-...@lists.debian.org; debian-devel@lists.debian.org; > debian-rele...@lists.debian.org > *Subject:* Re: Ability to further support 32bit architectures > > 于2024年1月12日周五 23:59写道： > > > > Keeping in mind that I am new to this arena... > > > > I have some Intel systems - both 64-bit and 32-bit - that I might be > able to use as build platforms. > > > > I guess all of your hardwares are 64bit. You setup different OS on them. > > No. I have multiple 32-bit systems, one of which is Intel. > > > What does the Debian team need from me to be able to use these systems? > > > > It's not about performance of hardware. It is about some limitation of > 32bit. > 2 examples for it: >1. if we use 32bit value for time, it will overflow in 2038, then > your time will be shown as 1900. >https://en.wikipedia.org/wiki/Year_2038_problem >2. A single process (or maybe APP, not precisely), can only use UP > to 4GiB RAM. >In fact on most system the value is less than 4GiB: > on intel32, it is 3GiB > on mips32, it is 2GiB >But currently, it is not enough, for example, when we build a > big APP, it will need much more RAM. >The RAM does install in your Rack, but you can NOT use it. > https://en.wikipedia.org/wiki/3_GB_barrier > > > I can't guarantee they'll be FAST, but I'll do what I can to make them > EFFECTIVE. > > > > If you are really need 32bit system. Maybe you can say out why you > *REALLY* need it. > For most users, the suggestion is: upgrade to 64bit. > > > That's not at all what I was asking or talking about. > > --J >
Re: Y2038 - best way forward in Debian?
What if we define an epoch to be 50 years and the epoch number becomes part of how the computer keeps track of the date. Something similar is done in astronomy I think, star charts always have an epoch. So epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050. Then we can keep a time_t at 32 bits. Things like strptime() and strftime() and ctime() would need changing but since they were valid in epoch 0 they'd only need to change for epoch 1 and later. A day will continue to be 86400 seconds of a 32-bit number but every 50 years the epoch would change. Dates can overlap epochs so 2020 could be part of epoch 0 and epoch 1. The year part of a time_t and struct tm ceases to be absolute like an hour isn't absolute on a 12-hour clock. It's probably been thought of. On 2/14/20, John Goerzen wrote: > On Tue, Feb 04 2020, Steve McIntyre wrote: > >> Arnd scanned the library packages in the Debian archive and identified >> that about one third of our library packages would need rebuilding >> (and tracking) to make a (recursive) transition. We can see two >> different possible routes to follow: >> >> A Follow a similar path to last time (rename library packages). This >>will allow us to do partial upgrades, but the cost is that a vast >>number of packages will need work to make this happen, >>*potentially* building library packages twice to allow us to >>continue both 32-bit and 64-bit time_t support forwards for a >>while. This effort will be *needed* only for the sake of our 32-bit >>ports, but would affect *everybody*. > > The thing that we have to remember is that an operating system is a > platform for running software. This problem is rather thorny, because: > > 1) Some software is provided in only binary form and cannot be > recompiled > > 2) Some software can be recompiled but makes assumptions about the size > of variables, may use int instead of time_t, and other assorted > messiness > > 3) Some software is going to break now, due to forward-looking time > calculations, and for others, it may be fine (or nearly so) even past > 2038 due to timekeeping being only ancillary to its purpose. For > instance, I have some old games that are binary-only and really don't > care what time it is. > > This option #1 sounds like a significant effort (because not only would > we need two versions of libraries, but also of include files). But it > certainly passes the "correctness" test better than your option #2. > > John > > -- - No, I won't call it "climate change", do you have a "reality problem"? - AB1JX Cities are cages built to contain excess people and keep them from cluttering up nature. Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Re: [openstack-dev] The end of OpenStack packages in Debian?
On Wed, Feb 15, 2017 at 7:42 AM, Thomas Goirand wrote: > Hi there, > > It's been a while since I planed on writing this message. I couldn't > write it because the situation makes me really sad. At this point, it > starts to be urgent to post it. > > As for many other folks, Mirantis decided to end its contract with me. > This happened when I was the most successful doing the job, with all of > the packaging CI moved to OpenStack infra at the end of the OpenStack > Newton cycle, after we were able to release Newton this way. I was > hoping to start packaging on every commit for Ocata. That's yet another > reason for me to be very frustrated about all of this. Such is life... > > Over the last few months, I hoped for having enough strengths to > continue my packaging work anyway, and get Ocata packages done. But > that's not what happened. The biggest reason for this is that I know > that this needs to be a full time job. And at this point, I still don't > know what my professional future will be. A company, in Barcelona, told > me I'd get hired to continue my past work of packaging OpenStack in > Debian, but so far, I'm still waiting for a definitive answer, so I'm > looking into some other opportunities. > > All this to say that, unless someone wants to hire me for it (which > would be the best outcome, but I fear this wont happen), or if someone > steps in (this seems unlikely at this point), both the packaging-deb and > the faith of OpenStack packages in Debian are currently compromised. > > I will continue to maintain OpenStack Newton during the lifetime of > Debian Stretch though, but I don't plan on doing anything more. This > means that maybe, Newton will be the last release of OpenStack in > Debian. If things continue this way, I probably will ask for the removal > of all OpenStack packages from Debian Sid after Stretch gets released > (unless I know that someone will do the work). > > As a consequence, the following projects wont get packages even in > Ubuntu (as they were "community maintained", which means done by me and > later sync into Ubuntu...): > > - congress > - gnocchi > - magnum > - mistral > - murano > - sahara > - senlin > - watcher > - zaqar > > Thanks for all of your work, Thomas. Wishing you the best. For others following along, we do have up-to-date versions of these packages in Ocata for Ubuntu. For a full reports of packages please see: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html > Hopefully, Canonical will continue to maintain the other 15 (more > core...) projects in UCA. > Thanks for the fish, > > Thomas Goirand (zigo) > > P,S: To the infra folks: please keep the packaging CI as it is, as it > will be useful for the lifetime of Stretch. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Corey
